Thoughs on Grbl-GCode-Sender

[phil-barrett]

After using GGS for a few days, I am quite impressed with the quality of it. Very well done. Program limits are a useful feature. I could have used this a couple of times in the past. Even with the arc issue, it's a great feature.

I usually use GRBLPanel but given that the owner has stopped supporting it, I've been looking for a replacement for GRBLPanel. I think this is it.

Some thoughts and questions:

• Com port, baud rate should be settable from the Settings: App panel. Would rather not have to restart with a command line option. Especially when using multiple boards.
• Visualization doesn't seem to work at all for me. Am I missing something?
• It would be nice to have jog and macro panels that don't obscure the main panel (i.e. allow them to be made permanent)
• Macro definition is not intuitive. You have to create the macro name and then edit it again to add the actual gcode. It would be more clear if there were separate new and edit buttons. New would essentially be the edit screen with the ability to fill in a name. As it stands, it seems like you are changing an existing macro when you create a new one. Also, there doesn't seem to be a way to delete a macro.
• How would it support an ethernet interface?
• On the grbl settings panel, I think there should be 2 modes - basic and advanced. Basic would show only the standard GRBL functions. Advanced, shows all. If basic was the default, grbl tutorials would be consistent with the initial view.
• It would be great if the MDI input and status showed up in the list of commands accepted by the grbl board.
• It needs a snazzier name than grbl-gcode-sender. It is an outstanding program and should have a outstanding name.

OK, one that is a huge ask and probably not happening anytime soon but I would love to see realtime GCode execution feedback. So 2 statuses: ok (received) and completed. I know it's a complex area and needs GRBL changes so it's hard(er).

Anyway, hope that's not too many things at once. GGS is already a fantastic program so please excuse my enthusiasm for making it even better.

[terjeio]

Thanks for positive feedback. The sender is still in alpha so early days...

• Settings: My idea was to have separate config files and use shortcuts if the sender is used for more than one machine. Path to the config file to use is a command line option.

• Visualization: What is not working? If the 3D View tab shows up it should work. If not it needs to be enabled in the App settings. Note that the rendering is currently a bit rough.

• Jog and macros: I am experimenting with this, be aware that keyboard jogging is available - so I do not understand why this panel/control is needed at all...

• Macro definitions: was put together in a hurry, to delete a macro delete the gcode and commit. I use a button with a pop-up menu for commands in my custom laser sender (add, save, delete), perhaps I should try a similar same approach for this control.

• Ethernet interface: supports simple telnet and websockets communication. Currently connection data needs to be entered on the command line of a shortcut or by editing the config file.

• Settings: One idea is to categorize the settings and use a grouped view. Mode can be implemented, the mode should then be put in the settings definition file (setting_codes_en_US.txt) as the UI is completely driven by that (in anticipation that settings available may evolve differently for ports - hardcoded for me is a no-no). Again, IMO a new project should be set up for handling grbl specs, this to avoid ports becoming incompatible. Preferably moderated by a third party not involved in porting or sender development... Kind of grbl standards body.

• MDI and status input: on my todo list. I have already made a response view control...

• Snazzier name: any ideas?

A lot can be done to improve the sender - and I have many ideas/plans. The UI could be made user configurable, drop in and arrange the controls you want from a palette. The 3D renderer needs attention, is currently too slow and should be viewable from the main tab. Camera view is too simple. Etc, etc...

[phil-barrett]

Some of this is about different expectations for applications. I'm in the visual/in the app control school of thought. Want to see buttons/controls/etc. Command lines and key presses require remembering or looking up syntax. So, of course you will hear stuff like that from me.

I saw how to do ethernet in the wiki after I sent the comments. sorry.

I didn't realize that Visualization needs an app restart to activate. That's a bit confusing. That will be a source of confusion by users. At the least, a note to restart the app would help there. Of course, immediately taking effect would be better.

I like the idea of a configurable UI. Especially if you have a way to save multiple and have them quickly available.

Name? Hmmm been thinking about it. GRBLizer? GSender?

I agree visualization needs to be sped up. I loaded one of my 10 hour tests (the big arc one) and it takes about 5 minutes to render but much shorter programs seem to take a lot of time too. I think arcs are part of the problem. Part of the issue is that you can't use the app while it's rendering. Maybe tie the rendering to opening the 3D tab rather than opening the GCode file as a stop-gap. I think some visualization programs allow viewing while running the actual rendering code in a separate thread. I will play with it a bit more, seeing some issues.

[terjeio]

Some of this is about different expectations for applications. I'm in the visual/in the app control school of thought. Want to see buttons/controls/etc. Command lines and key presses require remembering or looking up syntax. So, of course you will hear stuff like that from me.

It is ok to have opionions, but it is a chicken & egg situation that I have to resolve. The sender need to pull information from grbl to configure itself. So the communications setting can not (IMO) be moved to the App settings tab unless it starts up in the App settings tab every time. I for one would not like it that way. Similarily settings needs to be pulled from the ini-file as well, again that could be selected from the settings tab but practical? So IMO using shortcuts with command line parameters still has merit.

I didn't realize that Visualization needs an app restart to activate.

I am well aware of this, either a prominent message is needed or auto reconfig should be done. On my todo list already. Currently most of these settings require a restart.

I like the idea of a configurable UI. Especially if you have a way to save multiple and have them quickly available.

Of course layouts should be possible to save, if not I do not see the point of having such an option. And multiple layouts require selection, again I would prefer a shortcut with a command line option... Alternatives would be to require multiple instances of the sender or selecting a layout on startup.

---

The 3D renderer requires quite a bit of work before it is usable, and I would prefer to have a smaller version available in the main window. Currently the program list and the related buttons (Start Hold etc) resides in the same control. I want to split them in two and I am thinking about making a tab out of the program list and add a response log and a "live" 3D viewer as tab options to that. Partly because I do not want a large cluttered main window - the sender should be usable on a laptop.

I appreciate input, however implementation will take some time. For now I have focus on making the core functionality stable. Rewriting the main state machine to use function pointers now, in a similar vein to what I did with the original "spaghetti" state machine in grbl...

[terjeio]

My idea for adding a tab where currently the GCode list (Program) is :

Comments?

[phil-barrett]

I think that's a straightforward approach. One thing to consider its there would be 3 sets of tabs on the app - on the top, on the right side and bottom of the "output" panel. Each group is a little different. I think a UX person would want them to be more consistent (shape, placement, ...) but I'm not sure it will give us much benefit. Moving the output tabs to the top might be a good idea though it may be too busy with the tabs on the top close by.

[einencool]

Hello, today I've tested a little bit with your software, but these were only "Desktop Tests" with the Teensy Board liing on the table :-)

I like your software very much, but I also have some questions for updates. I have no idea from coding, so I can't mention how much work it could be.

I like your implementation of the jogging commands. And the Software (alpha 13) looks fast and reduced to the important things...

I'm controlling my CNC with a bluetooth keypad, so it would be great to optimise the software for more keypad control :-)

These are my "points for improvments...":

• different Step / Jog size/speed for XY and the Z-Axis (to drive the Z-Axis slower than the other axis)
• Keymapping for Macros / Start / Pause / Stop / Check
• Maybe a way to maximise the software on a screen, because it looks so small on a 24 " Screen
• I come from bCNC and it's nice to see in the "3D-View" how much from the program was done ( the part that was ready was shown in green) But I don't know if it is much work and if it will "blow up the code". It's just a "nice to have"
• Is there a way to show the "remaining" time? This was also shown in bCNC. The software was good, but it hang up to often and costs me to much of my workpieces...

So in the next days I'll try your software with my old Arduino Mega controlled CNC (if it is possible)

[terjeio]

different Step / Jog size/speed for XY and the Z-Axis (to drive the Z-Axis slower than the other axis)

Have you tried keyboard jogging?

Keymapping for Macros / Start / Pause / Stop / Check

Some are assigned already, but I guess you want user defined binding. Will put on todo list.

Maybe a way to maximise the software on a screen, because it looks so small on a 24 " Screen

Om todo list (perhaps I should publish it?), initial design goal is that is should be usable on a laptop with limited resolution.

...see in the "3D-View" how much from the program was done...

Will have to investigate this, not sure how complicated it will be. Perhaps moving the vectors to a different path collection will work, this since it is the path collection that is assigned properties such as color.

Is there a way to show the "remaining" time?

Not yet. Doable since the program parses the gcode on load.

---

My main proirity for now is to make the program robust and add what I consider as core functionality. Currently I am working on probing, the gcode parser needs attention as does the 3D rendering (not all G-codes are supported). Additional lathe wizards is also high on my agenda, I guess not what most users would want - but I want those for my lathe rebuild.

[einencool]

The keyboard jogging is really good, the only thing is, in my thoughts, on a machine with a size around 1000x 600 x 200 mm it would be nice to drive the XY axis faster than the Z Axis, but that was only a thought :-)

For the key mapping you can define them to your preferences. Today I have the "Auto Hot key " program to remap them on my Bluetooth keypad.

I have it also tested on my 15" laptop, but there is also the high resolution the problem that I have to sit directly in front of it to see what I have to click.. :-)

Like I said, I only make a test on the bench, it seems yesterday in the evening that I had a "NC" file with G17 and G19 commands. The sender stopped at these, he semms not to know what that is. Could that be, or is there an issue in my file?

Thank you for your continuous improvement. The software has a lot of potential. 👍

[terjeio]

@einencool : if possible please attach your problem file to a comment so I can use it for debugging.

[einencool]

Hi, this was the only Code in this program, it was to clear only one side. `G90 G94 G17 G21 G54 S12000 M3 X125.6 Y35.2 Z15 Z5 G1 Z1 F333 Z-4.4 G19 G3 X125.6 Y35.8 J0.6 F1000 G1 Y36.4 Z-5 G17 G3 X125 Y37 I-0.6 G1 X0 Y37 F400 G3 X-0.6 Y36.4 J-0.6 F1000 G1 X-0.6 Y35.8 G19 G2 Y35.2 Z-4.4 K0.6 G0 Y35.2 Z15

Z20 M5 M30 `

On this Laptop I don't have your Software installed, so I can't say if it was wrong. I think it will work, because on my other Software, the Code in "Check Mode" also gives an error, but it works.

Then I tried your Software on my actual CNC Router with an Arduino Mega. Well I've had some Problems with it, because while jogging sometimes the software didn't response or better to say it doesn't move any more. I could click in every single window oder every button, but I have to press the Reset button so that I can move forward.

But then it happens, that i shortly press the right key, and the spindle moves a long way until I pressed the Reset key. It was my Luck that I was far away from my workpiece, otherwise it would have killed my bit...

But after that I switched back wo my "normal software" and worked with it the rest of the day.

[phil-barrett]

grblHAL doesn't like the G2 and G3 lines. Not sure what is wrong with them. G17 and G19 are OK.

[phil-barrett]

The first G2 is the offending one. I changed it from

G2 X125.6 Y35.8 J0.6 F1000

to

G2 X125.6 Y35.8 R2 F1000

And grbl accepted and ran the program. Note that R2 was just a guess. It also accepted all the other G2s and G3s. Something in the J0.6 is wrong but I don't know what. Here's whole program that gets accepted.

G90 G94
G17
G21
G54
S12000 M3
X125.6 Y35.2
Z15
Z5
G1 Z1 F333
Z-4.4
G19 
(G2 X125.6 Y35.8 J0.6 F1000)
G2 X125.6 Y35.8 R0.6 F1000
G1 Y36.4 Z-5
G17 
G2 X125 Y37 I-0.6
G1 X0 Y37 F400
G3 X-0.6 Y36.4 J-0.6 F1000
G1 X-0.6 Y35.8
G19 G2 Y35.2 Z-4.4 K0.6
G0 Y35.2 Z15

Z20
M5
M30

[terjeio]

@einencool

There is a problem with your program, line 11 reports error 33 (motion command target is invalid). grblHAL (depending on compatibility level) is a bit more strict than other versions, it does not allow the program to continue after an error as this may cause accidents. This may be the reason it stops. Also, I guess my sender is more strict than others in handling errors in programs.

Keyboard jogging with other firmware than grblHAL: Jog cancel is buggy and does not always work. Only workarounds has been suggested for that, not a fix for the underlying bug(s). I have made a version for the Arduino Mega with what I believe is a fix, you may try that. It was recently brought up here by @shaise who also has suggested a fix. I have warned about the issue in the wiki, but it is perhaps better to make the keyboard jogging a configurable option when using other firmware than grblHAL.

Pressing the Reset button is sometimes the only way to continue, again for safety reasons. I need to put more information in the wiki...

Anyway, many thanks for your feedback - very useful for bringing both grblHAL and the sender forward. And thanks to @phil-barrett too for helping out.

[einencool]

Hi @terjeio like I mentioned in the Teensy Topic, I would like to give you some points for your Software. Maybe there are some Points you can solve :-)

I'm using my old CNC with an old Playstation 3 Controller and map the buttons with "Joytokey" to some keyboard keys. So I don't have to look every time onto the monitor when I'm starting my job.

1: Realtime Jogging is now optional, I think that is a good point. But maybe you can make Shortcuts for the "normal" Jogging feature like your keys left / right and so on for "normal" Jogging with the step width choosen in your "Jog" Tab. So if you press left, the gantry will move e.g. 0,1 / 1 / 10mm left. Maybe you can map the "Numpad" keys 1/2/3 for 0,1 / 1,0 / 10mm step width. Or you can adjust it like before with Shift and Ctrl or Alt Key for different Step width. That could also be mapped to the Gamepad...

2: Shortcuts for macros, so I can start them with a button.

3: Look and feel: Please maximize the Screen :-) On a bigger Monitor it doesn't look so good Please place the step side to the main page or the complete Jog-tab, so that you can see, which movement you are doing.

4: Probing Tab It's great to see, I didn't start it now, but it would be nice to have two Options for Probing speeds for fast and slow probing for more accuracy... I've done it till now with a macro, but your Center finder looks also nice. Is it possible to calculate these Positions to an offset when probing with an external pin?

Maybe you can do some of these Things because I think your Software can be very good, it's very lightweight and fast, I like that.

Thank you so much :-)

[phil-barrett]

If you add maximize, then please also add minimize.

[terjeio]

@phil-barrett minimize added, easy to miss out on obvious stuff when focused on internals...

@einencool Thanks for input. Generally I think I am slowly getting a understanding of how the WPF/MVVM coding pattern should be used and from I have learned, and used, I believe the codebase is now approaching a useful and relatively stable foundation to build upon. I have chosen to split the sender in many different projects for a number of reasons, one is to be able use the different pieces to build targeted apps (I have one dedicated for my CO2 laser), another is to ensure that I adhere to the coding pattern rules. This means that I have put some restrictions on how I want to implement stuff. My main focus this far has been on internals, not the UI, as I want the basic stuff to be as clean and robust as possible.

1. Jogging There should be no reason to not enable keyboard jogging when the firmware is gblHAL, regardless of the COMPATIBILIY_LEVEL setting. Note that it is enabled automatically for some levels. Step jogging is active when the cursor keys are modified by the -key, perhaps one idea would be to bind the step size to the one selected in the jog control?

Adding further shortcut keys such as executing macros or selecting stepsize is something I have already started looking into, I want that to be a part of a single centralized class shared by a number of subscribers to keypress events. Currently the code is a little bit too tightly coupled to other code to achieve that.

I do not own a gamepad so I have no idea of how flexible the configuration for these are the via Joytokey app. If you can bind keys on the keypad to the same keycodes that the cursor keys and the modifiers provide keyboard jogging via the keypad should work "out of the box".

2. Shortcuts for macros - see above. Should be bound to the function keys only?

3. Look and feel. On todo list - I have an idea that the UI should be user definable. The MVVM coding pattern allows that. It kind of is already, but that requires a bit of coding... The main project, GCode Sender, is surprisingly little code - its purpose is mainly to glue all the components together to form the UI.

4. Probing. The idea is to make the left hand side parameters selectable from user defined profiles (via a drop down), a bit similar to how lathe mode profiles are implemented. You can check that out by setting the lathe mode in Settings: App to Diameter or Radius and restart. Tabs for Threading and Turning will then show up.

I need users to test and provide detailed feedback for the probing functions, I am no expert in this area. And I need to get/make a probe or two, testing this far has been with a tool.

---

I have spent a lot of time on this project lately, and I have a bunch of others I want to focus on now as the spring is coming. A garden, a lathe waiting for its new lead screw+++. Give me some time and hopefully I can make you all happy.

[einencool]

When the real time jogging works with grblhal without problems, it's no problem, then you can leave it as it is. On my old cnc I've set my step width "normally" to 1mm and when I press the key left or right on the gamepad the button will be mapped 20-times per second, and when I change the step width it will be moving slower or faster. Then I use another key press and I can only move one step per time to find my edge or something like this.

I think the one step per per time width should be aligned to the step width choose in the jog box, so you can make precise movements and "know" how far you move...

I can map up to 4 different keys to be pressed with one button simultaneously. E.g. Ctrl-Alt-Shift-"A" for one command, so it's no problem if you give maybe 12 different shortcut keys e.g. Shift-"F1" and so on and then the user can map them to different functions. You can have a look at "Bcnc" there are all different versions for the "F-keys" and they can also be used for own macros. That would be good enough.

When it would be possible to get the shortcut upgrade and the adjustable "single-step-width" per jog-step-width e.g. 0.1mm and so on, then I would definitely test it with my new machine when it will be ready. But I think it will last for around 2-3 weeks.

Thank you for your great work and help. Greets Chris

[terjeio]

New release up for testing, this is quick and dirty implementation of enhanced keyboard step jogging. It requires keyboard jogging enabled and will always use the step feed rate from Settings: App (this is not going to change). The current step distance will be displayed in the lower right corner of the Grbl tab and can be changed with numerical keypad buttons 4 and 6 (when num lock is enabled).

The jog pane Distance radio-buttons will be synced both ways - but not sure if this is wise. Same goes for the longest jog distance (10mm/1inch) - it is currently selectable with the shortcuts but I am not sure this is wise either. I would certainly vote against having that selectable.

Step jogging is activated when the <CTRL> modifier key is pressed, note that this mode does not support autorepeat (and never will). IMO longer jog distances should be performed without this modifier or with <SHIFT> modifier key for faster feedrate.

Note that the initial step distance will be set from the step distance value from Settings: App , this is a feature, not bug. Also note that those who have a keypad attached directly to the controller will not see the Keypad jogging frame in Settings: App, this since parameters for jogging is read from the firmware (set viaSettings: Grbl) in order to keep keyboard jogging consistent with the keypad.

I might be persuaded to allow step keyboard jogging for non-grblHAL firmware when keyboard jogging is not enabled, this since the autorepeat feature is not used and jog cancel never sent.

Test with care! - as I have not done much testing myself...

[einencool]

Wow, that was fast...

I'll try it in the evening with the new PC that I want to use with the new cnc Maschine.

I think, that I have explained it not so good in my previous post. In my opinion it would be good only to adjust the single step width with the "Step width" from the jogging tab. The original jogging was ok for me. Only on my old cnc with the arduino Mega was a little bit faulty... The speed was adjustable in the settings tab, so that was all ok and very smooth

[terjeio]

@einencool

Only on my old cnc with the arduino Mega was a little bit faulty...

My patched version for Arduino Mega should work ok with keyboard jogging enabled.

[einencool]

When I would use the cnc for further operation, I would think about it. But this cnc will be removed when the new one is ready, so never touch a running system :-)

[terjeio]

Build Alpha-0.17 is now up. Resizable UI++

[einencool]

Hello @terjeio , Today was the first time, I fired up my new CNC with your latest GRBLHal and your Sender Nr 17. I make the first moves with it. After some different Probs, I got it to work, but one thing was really strange while jogging the machine. When I use the „Realtime“ Jogging Commands with the arrow keys, every time when I release the button, the machine makes a quicker move at the end. This is in Slow and fast mode visible. When I set the acceleration to 10 mm/sec2 then it was very good visible. When I jog with your 10mm or 1mm/button controls, everything works as it should. The machine slows down as it should. I don‘t know if you can understand what I‘m writing g Do you know what could be the problem? In the next days I‘ll try a little bit more. I hope tomorrow I‘ll get the spindle working.

[terjeio]

@einencool : can you add your grblHAL settings to a comment? The easy way: select File > About in the sender and press the To Clipboard button, then you can paste the settings into a comment.

[einencool]

Thank you for your fast reply, I‘ll post it tomorrow. Hopefully you can see what is the Problem :-)

[einencool]

So, finally, I got all the data from the PC :-)

% ; grblHAL ; 1.1f(Teensy 4.0).20200416 ; [OPT:VNMTSL+,35,1024,3,0] ; [NEWOPT:ES,TC] ;[DRIVER VERSION:200413] ;[DRIVER OPTIONS:USB.2] ; $0=10 $1=25 $2=0 $3=0 $4=0 $5=0 $6=1 $10=382 $11=0.010 $12=0.002 $13=0 $14=8 $15=0 $16=0 $17=0 $18=0 $19=0 $20=0 $21=1 $22=17 $23=0 $24=25.000 $25=500.000 $26=250 $27=2.000 $28=0.100 $29=0 $30=24000.000 $31=6000.000 $32=0 $33=400 $34=0.0 $35=25.0 $36=100.0 $37=0 $39=1 $40=1 $41=0 $42=2 $43=1 $44=4 $45=0 $46=0 $56=5.0 $57=100.0 $58=-5.0 $59=500.0 $60=0 $61=1 $62=0 $63=3 $64=0 $65=0 $100=320.000 $101=320.000 $102=320.000 $110=1500.000 $111=1500.000 $112=1500.000 $120=1000.000 $121=1000.000 $122=1000.000 $130=570.000 $131=750.000 $132=170.000 %

[terjeio]

Thanks, I have tested a bit (but not with a machine connected) and cannot see any unexpected behaviour.

Be aware that when jog cancel is sent on key up the movement is decelerated to a stop. If the jog speed is high and acceleration setting is low there can thus be a significant delay before movement stops. Try experimenting with the keyboard jogging settings in Settings: App in order to find values that suits you (and your machine).

Button jogging via the jog flyout sends short distance jog commands that is not terminated with jog cancel and will therefore behave differently.

[einencool]

Well, I tried today a little bit more, but it makes no difference if I put a acc of 10 or 1000 for the axis. Also the distance is not the problem if the max speed is reached, then every time at the end it makes this scary move. On every axis. When I look at the screen everything looks fine. It's only visible for me, when the machine is moving.

When I switch to the one key press jogging, then it accelerates and brakes as it should. And the machine is capable to be moved with around 10 m/min and now I'm on a speed with 1.5 m/min

Since I have no other software which supports real time jogging with the Teensy and your GRBLHal, I can't test it otherwise. In this case I'll make some tests with the UGS Platform software in the next days... But I don't know if it will work out of the box with the grblhal in compatibility mode 0, but I'll see it then :-)

With best regards Chris

[terjeio]

I checked again with my scope - then I saw it. So you are right, there is an issue. I have checked with two other processors/drivers, they do not show this issue so perhaps a driver problem.

My initial attemps at solving this has failed - so I suspect this may be a tricky one to track down. I miss having access to a debugger...

[einencool]

Ah Ok, the good thing is, that it's not only on my machine, but it's not so good to hear that you don't know what the problem could be. Especially when it's only with the Teensy and not with other boards.

[terjeio]

@einencool : can you try with commenting out #define ADAPTIVE_MULTI_AXIS_STEP_SMOOTHING in grbl/config.h (line 258)? I do not see the issue on my scope when I do that. I guess it is a good lead - however, I have to go shopping now so will have to follow that later.

@shaise : no, I've checked the STM32 and MSP432 drivers - both seems fine.

[shaise]

@terjeio, Yes, I tried using the same settings @einencool uses on the STM32 on the real CNC and I can confirm it works with no issues. thanks.

[einencool]

@terjeio Thank you for your Help, this works for me, and now the moves are really smooth, like it should be. So I finished the mechanical assembly today, and wanted to make my first moves with the machine.

But then I got a Problem with my Z-Axis, but this I'll look for in your GRBLHal Repo, because it seems to be a little Problem with the "Direction" Signal for the Z-Axis. It doesn't power the direction Pin. So I changed the Z and the A Axis Direction Pin in the Config (Pin 7 & 9) but that also doesn't move. So I finally changed the Z and Y Axis, and that also doesn't fire up the direction Pin for Z, but for Y it does, so I think the wiring is not the Problem, it seems to be in the Config. So I have to look for it, but maybe you know where the Problem could be. In your Software the DRO for Z goes in the desired direction...

[terjeio]

@einencool : I belive I have fixed the issues now, Z-axis was due to me commenting the Z-axis output for debugging and forgetting to remove the comment. Jog problem was a bit more subtle and did not only affect jogging - sloppy coding from my side in an IRQ handler combined with (IMO) strange timer behaviour seems to be the reason for that.

So, please try this fix with ADAPTIVE_MULTI_AXIS_STEP_SMOOTHING reenabled and report back.

Thank you for your patience.

[einencool]

Hi @terjeio that seems to work pretty good. The next Problem I have is while Homing. I don't know whats the Problem, when I press the Home Button, the Z-Axis homes and then the machine stands in Idle. I think the Problem is, that I have to enable default homing in the Config, but now I made a "Reset" from the Config, and now I'm trying to connect to the Teensy since 40 min and I can't get the "GRBL" Settings because it doesn't seem to connect ... For now I give up and open a beer g

[terjeio]

Can you connect with a terminal program like PuTTY? If so does the status response include |Pn: with D in its parameter list?

[einencool]

I don't know how to connect with putty to this device, but in your program it says that the door pin is open (the pin is not connected to the breakout board, because it is on the underside of the Teensy and this pins I didn't solder / that's why I also didn't have the eeprom) I tried to invert the signal in the config, but this didn't solve it.

When I start the "UGS Platform" and try to get the Status, it says Grbl didn't finish booting...

[terjeio]

Ok, then comment out line 133 in driver.c to kill the door signal permanently.

//#define SAFETY_DOOR_PIN (29u)

This signal is a pain because it disables everything when asserted...

[einencool]

👍 Just right now, I took the Teensy out of the Breakout Board and soldered the 5V USB Pin bridge. When I only connect the Teensy without the Breakout Board, then everything will be displayed as normal, only the signals are red, because no Signals are on the board. Now in your Software all 6 Buttons are shown and I can access all the GRBL Settings. When the Breakout Board is connected and the 5V Pin is disconnected, then only 4 Pins are shown and I can't change anything in the Settings.

But now I'll disable the Door Pin 👍

[terjeio]

Ok, I wrote driver.c, the setting is in driver.h. Sorry about that.

[phil-barrett]

Sorry to be a bit late to this. Einencool, did you earlier cut the VIN/VUSB connection on your Teensy 4? (see red circle in photo) If so, that is why the BoB wasn't giving you anything - +5V is needed to power the optos for all the inputs.

Inverting the door pin has worked in the past. But I just checked an up to date build with a bare T4 and TSender and there seems to be a problem. I can invert the door signal and it shows as inverted but doesn't allow me to reset/unlock. When I save grbl settings and power cycle the T4, the door pin reverts to uninverted. Inverting other pins like limits works and persist across power cycles so it is saving some of the settings at least.

[einencool]

No problem, after the last few days, I know some of the interesting points :-)

I reflashed the device, set the conf8g and then I desoldered the 5v pin and put it back into the breakout board. Now everything is working as expected and the homing routine was working without any problems.

So I have to thank you for your continuous and fast support 👍 💯

:edit I have cut the 5V connection, but the Teensy is always powered with external 5v from a power supply. So that should not be the problem. If I haven't powered up the 5v, then the Teensy doesn't connect with windows.

[phil-barrett]

And by the way, with a bare Teensy 4, you will also need to invert the e-Stop pin.

[einencool]

Yes you're right, but on my, machine the "Start Hold and E-Stop" are NC- Buttons, so then there is no problem. But sadly I noticed after soldering and wiring the board, that I had to solder the inner points on the Teensy for the eeprom and the safety door. But for now it's OK.

[phil-barrett]

Yes, the Teensy 4 backside pins are an issue. I've gotten pretty good at soldering them but managed to desolder one of the 402 caps on the first one I did. Was able to replace it but not fun.

The good news is PJRC is about to release the Teensy 4.1 which has even more pins and all are on the edges for easy soldering. No more back side pins. I have a PCB design for it ready to go to the factory, just waiting to make sure they don't change anything. 5 axis and more goodies. Much more DIY friendly. If you want, I will send you one when done. no charge.

[einencool]

Oh, that sounds really interesting. I'll give it definitely a try, thank you for this Great offer 👍 Do you know when it will be available?

[phil-barrett]

I don't know when. PJRC says they will release the T4.1 in May (Covid delays are possible) and it will take a week for me to get the first PCBs. I'll will need a few days to verify and test so probably some time in mid June. I'll let you know when I know better.

[einencool]

That sounds good. I think in the next 3 weeks I'll get my new JMC Motors and then it'll be a good time for changing the pcb 😀

[terjeio]

Inverting the door pin has worked in the past.

This depends on it asserted state, if asserted then grblHAL (and grbl) enters suspend mode and only responds to real-time commands. This is the reason why the door input is sometimes a real pain, and I am contemplating disabling it as default.

[terjeio]

Safety door switch handling is now disabled in the core by default.