Command to 3rd serial port sends commentary as well

[amoineau]

Description

Hello ! I'm using the 3rd serial console and I send command using the fields "G-code generation>G-code Header/G-code footer" and "Clipping>G-code before tile". The commands work, for instance "(^3 $SH1)" allows me to open the shutter, but grbl-plotter also send the commentary that you add in the gcode :

Expected behavior

It would be nice if it could only send the command.

Screenshots

I lost my screenshot of the console log, I can make a new one later if you need.

[svenhb]

Please try https://github.com/svenhb/GRBL-Plotter/blob/master/GRBL-Plotter_1575_publish.zip

[amoineau]

Thank you, I should be able to try this afternoon.

[amoineau]

Summary

Now, in the console log, everything looks as it should but it doesn't act as it looks.

Some context

The two main things I need to control through the third COM during the process are a shutter for the laser and the conveyor. Obviously, I need the process to wait for them to finish after sending a command.

Example Before every tiles (but the first) and after the last I ask the conveyor to move forward 1m.

Result In the console I see the command being sent and when it's done the handshake occurring, but the CNC process is not held and the machine continue lathing / marking at the same time.

I don't know if it's a new problem, if it's still the same as before or if it's one that was already there but "hidden" by the previous one. What is weird is that I believe this whole process used to work when you first implemented it.

[amoineau]

Of course the first thing I questioned was our board so I tried and changed the handshake message in GRBL plotter to make sure that our board couldn't possibly release the hold and the behaviour was exactly the same (just waiting for the timeout instead of handshake) plus I would see the message in the log as it was send if our board was misbehaving. Edit: typo on "possibly"

[amoineau]

Additional (but uncertain) information

It seems that GRBL-plotter is not completely ignoring the pause. The pattern is not very consistent but I feel like, when it supposed to stop :

• it pause for a very short time (perhaps just the tool change)
• the conveyor starts moving
• it does a few commands
• then stop and wait for the handshake Edit : the conveyor usually stops somewhere here and the execution resume

I don't know if that will be helpful but it seemed meaningful. Maybe the streaming overshoot when it should stop for the (^3 xx) command ?

Edit : I just ran into a case where I realised the (^3) command would happen before it was supposed to, which potentially also matches the behaviour described above. Maybe the "it does a few commands" were actually the commands it was suppose to do before the conveyor moves.

[svenhb]

Did you increase the timeout time inside the 3rd serial dialog?

The intended flow is (just theoretically tested):

• Send a command to 3rd serial, GRBL-Plotter stops and wait until
• 3rd serial receives the "Busy-end keyword" or timeout timer reached end (default 3 sec, max 100 sec.)
• GRBL-Plotter continues it's work...

[amoineau]

Yes most of the time I use timeouts above 30 sec because the conveyor takes some time to move.

[amoineau]

Hi ! By any chance, did you get the time to look at it ? I know it's a bit vague, don't hesitate to tell me what I could do to help isolate the problem. Maybe I can send you a DXF I tried with the converted G-code and a description of what's happening (even a video perhaps) ?

[svenhb]

No, I didn't do further checks up to now. Perhaps you can send me the machine-settings (File - Export Machine Settings), also the scripts you may use for tool-change. Also a more detailed descritpion would be nice... Does the time-out comes first or the key-word of the 3rd serial?

I will make a quick program on an Arduino to get a real "client" for the 3rd serial to do tests.

[amoineau]

Ok ! I'll make all of this tomorrow, sorry I didn't catch you message this afternoon.

[svenhb]

I tested now with two controllers and they behave as I expected. In the gif below: I attached a button to the Arduino of the 3rd serial, which I press when needed - the Arduino then sends "ready". Find here the used version 1.5.7.7 with a bit more log-info: https://github.com/svenhb/GRBL-Plotter/blob/master/GRBL-Plotter_1577_publish.zip

[amoineau]

It's taking me some time to set everything up but I'm almost there, I wanted to make sure that I did everything cleanly. In the meantime I have an error with the version 1.5.7.7 that you linked. The 3rd serial port does that when it starts (after the first time, when I chose the right serial port, rate and handshake string) :

If I re input the settings and close/reopen the COM, it works but I have to do it every time.

*The cropped message is : "cannot be empty".

[amoineau]

May I ask what you used to record your screen ? I intended to use the Windows built in screen recorder but I cannot capture the whole screen, only one window. So I can't get GRBL-plotter's 3 windows. *I cannot download unverified softwares on the PC I'm using with the machine.

[svenhb]

It was a tip from an other user:

[amoineau]

Thank you, I'll see if I can install it and i'll try. I met other problems but the demo I wanted is finally ready, I'll record what is happening. Edit : there is a portable version, great !

[amoineau]

Here are all the resources for 2 examples : #188.zip

It includes :

• The original DXFs.
• The converted g-codes.
• A gif of one example (second is coming but the record takes forever to save/encode).
• The grbl-plotter machine settings (.ini).
• The grbl controller settings.

I tried making a video of the record in addition to the gif so you could pause but it's 4gb :s so i'm trying another compression system.

[amoineau]

First example (polyline-laser-long) :

This file is suppose to be a polyline spanning across 4 tiles. The generated g-code is exactly as expected :

• Shutter opens ($SH1)
• First tile
• Conveyor command ($CP1050)
• Second tile
• Conveyor command
• etc

But when the file starts GRBL-plotter sends shutter and immediately after a conveyor command, which shouldn't be there and doesn't block the process (the head moves even though the flag hasn't been cleared). Latter during the tile the flag is cleared (it takes ~18 seconds for the conveyor to move). When the first tile is finished the conveyor command doesn't occur (probably because it already did) and the process starts the second tile. After that the process behave correctly, the command is sent at the end of each tiles and it waits for the flag to be cleared.

[svenhb]

If I run your polyline-laser-long.nc, file, it stops after $SH1 and continoues after I press my button... In your gif, rigth after the $SH1 a comment and the READY key-word is received... This is probably the problem - you should send the READY when it is ok to proceed, not if the command was received...

[amoineau]

$SH1 returns ok (READY) once the board has relayed the message to the shutter, so it is almost instant.

[amoineau]

When you try with your setup, is the $CP1050 sent right after (so at the beginning of the tile) or at the correct time (at the end of the tile) ? And does the head moves while it shouldn't (after a command but before a READY clear) ?

[amoineau]

I'll make a program like yours to send READY on demand. It might help and that way I can test directly at my desktop (it takes forever to setup tests on the machine plus transfer files between PCs).

[svenhb]

I think the ready after $SH comes too fast, can you build in a delay (perhaps 1 second) before sending a READY?

[amoineau]

I think the ready after $SH comes too fast, can you build in a delay (perhaps 1 second) before sending a READY?

I'll do as I said just above first, it should tell us if that is the problem. I have a meeting now, but I'll be back on it in an hour. Thank you for your help !

[svenhb]

Ok, slowly I can see the problem: (^3 $CP1050) will be send, but the previous code is not completed... This happens if the tool stays at coordinate 0;0, if the tool is somewhere else, it doesn't happen. Somehow there is a problem to get the "run" state before the code in front of (^3 $CP1050) is completly streamed...

[svenhb]

Perhaps you put a G04 P1 in front of your (^3 $CP1050)

[amoineau]

On the second file the problem tends to happen on every tile, no matter the position, I wasn't able to get a proper recording yet because I have problems on top of my problems and I can't get the same run twice :(

[svenhb]

I assume the gcode up to (^3 command is procesed too fast and the grbl-controller is still in "IDLE" when it comes to (^3. GRBL-Plotter waits for the transit "RUN" to "IDLE" before sending (^3...

[amoineau]

Ok I ran some test with a board to send the ready manually and I got the same results as before on both files. It seems that (^3$CPxx) commands SOMETIMES trigger to early. Then I removed the $SH command entirely and the first first file (polyline) worked correctly, the second one worked better but I still had a problem on the 5th tile. The command was sent to early but once it reached the spot where it should have sent the command, the process waited for the clear correctly.

[amoineau]

Perhaps you put a G04 P1 in front of your (^3 $CP1050)

I'll try that

[amoineau]

The pause before CPxx doesn't seem to change anything..

[svenhb]

Ok... The "only" problem is (^3$CPxx) commands SOMETIMES trigger to early. - right? If you check ControlSerialFormInterface.cs function processSend() (^3 will only be sent, if

• grbl-buffer has enough space to take the command, and
• grbl state is IDLE

I assume grbl-controller is too slow to get "RUN" state and the (^3 command will be sent... You use a Mega right? I just test with Arduini Uno = 127 byte buffer...

Perhaps I should check if the grbl-buffer is nearly empty... I can try this later today.

[amoineau]

Well in this case the problem is CP because it is what I use frequently. But for instance the SH0 at the end fails on some files too so if I were to use other commands extensively it would probably behave the same :/

For grbl, in my office I use an arduino uno for the simulation but on the machine it is a custom board with an atmega 2560. For the second controller, it is a second atmega 2560 (on the same board).

[amoineau]

I'll try to get a mega in my office for more accurate simulations.

[svenhb]

I added a check if the grbl-buffer is nearly empty: https://github.com/svenhb/GRBL-Plotter/blob/master/GRBL-Plotter_1578_publish.zip

[amoineau]

By re-reading yesterday messages I just realised : the (^3) commands are sent to GRBL ? I imagined the grbl controller was blind to the 3rd controller manipulation's, like we were just asking it to pause.

I'm checking the new version.

[svenhb]

the (^3) commands are sent to GRBL ?

No, they must be sorted out and send to the 3rd serial, but only if 1st serial (=grbl) is in IDLE mode, to synchronize both controllers. If the 1st serial-grbl is in IDLE we can assume the buffer is empty and all commands were processed.

[amoineau]

I made a quick test on both file (still with an arduino uno) and it worked as intended ! Before I get to excited I'm going to check with other files and a Mega board.

[amoineau]

the (^3) commands are sent to GRBL ?

No, they must be sorted out and send to the 3rd serial, but only if 1st serial (=grbl) is in IDLE mode, to synchronize both controllers. If the 1st serial-grbl is in IDLE we can assume the buffer is empty and all commands were processed.

Yep ok, make more sense, I wasn't fully awake ^^

[amoineau]

By the way, the changes to the formatting in the console are very nice, especially the timestamp !

[amoineau]

Ok, I tried every file I had with the "simulation" setup and it worked. I tested 2 of them on the machine and the result were the same, I'll try more with time but it looks good !

[svenhb]

Sounds good 👍

[amoineau]

Thanks again for the support 🥇