DIYcontrol port, immediate commands are not supported

[deHarro]

To support jogging with dedicated joystick hardware according to "GRBL V1.1 Jogging" via this second DIYcontrol port, the handling of immediate commands has to be supported.

This implies:

• The receiving thread in GRBL-Plotter has to accept single characters over the serial port
• GRBL-Plotter must not wait for CR LF to treat the received character
• Instead, GRBL-Plotter has to accept every single character on this port when it arrives and forward it immediately to GRBL on the CNC port.

Besides that, to prevent accidental forwarding of jog commands, GRBL-Plotter has to block input on the DIYcontrol port as long as a CNC job is running. I suppose, that is already guaranteed since there is the "virtual joystick" in GRBL-Plotter.

[svenhb]

I will implement somthing like this: receiving char by char, filtering char > 0x7F -> send real time command, or collect further chars until /r/n is reached, then send by regular function.

[deHarro]

Might work, lets see how it performs... :-) Thanks!

[svenhb]

Try test version https://github.com/svenhb/GRBL-Plotter/blob/master/GRBL-Plotter_1202_test.zip were I implemented my suggestion. Could not test real time commands, because no hardware which can send, I hope it works.

[deHarro]

Something went wrong :( You double every Jog command and GRBL doesn't understand that.

Coordinates in GRBL-Plotter dont change.

It's not clear, whether the realtime command is forwarded to GRBL or not.

(You said, you have a spare Arduino. Are you willing to buy a joystick at ebay? If so, I happily send you the sources of my joystick controller for testing. But we can try debugging together, no problem)

[edit] For testing on your own, I can provide you with a firmware for your spare Arduino that sends jog commands on triggering a switch. [/edit]

[deHarro]

This is my test equipment at the development computer:

The right Arduino has one stepper on the X axis to get the feeling when stepping, since one is fooled by the changing numbers in the different applications I use when developing, sometimes.

The left Arduino runs the joystick firmware, I can control X and Y, Z is fixed centered in software. If necessary I can attach one button, the thumb joystick features a NO switch by pressing the knob.

[svenhb]

But realtime command works?

[deHarro]

As I wrote, I cannot verify that. To proofe the functionality, GRBL-Plotter and GRBL have to execute the jog commands and then the jog-cancel can cut in and stop the motion underway.

As long as the jog commands are not forwarded correctly... no chance to test. Sorry.

[svenhb]

Try new version, hope it works as expected: https://github.com/svenhb/GRBL-Plotter/blob/master/GRBL-Plotter_1203_test.zip Perhaps have a look to issue #27, #29, #30, #31, #33 and close them if ok

[deHarro]

Sorry, same effect as before:

[svenhb]

Aber jetzt: https://github.com/svenhb/GRBL-Plotter/blob/master/GRBL-Plotter_1204_test.zip

[deHarro]

Ok, one step beyond :+1: :-) The jog commands are forwarded perfectly now.

But how sure are you, that 0x85 chars are transmitted asynchronously and bypassing the already sampled strings (or string parts)?

As far as I can judge from my seeings, this part of the job has potential... will say: That doesn't perform well.

I just fed some seconds of very small and slow but following sequently fast movements into GRBL-Plotter, the stepper motor follows. Fine so far.
(Explanation: "very small": X=1 mm, "slow": F=84, "following fast": every 10 ms)

Then I released the joystick, what should issue the jog-abort commmand (0x85). But the stepper happily moved on for around half a minute or so, before the somewhat faster movement came to GRBL. I even changed rotation direction for some time. This reached my motor after around a minute or so.

This leads me to assumption that the abort command is not forwarded passing by the already sampled jog commands.

I try to manage to visualize the characters from my joystick to GRBL-Plotter on the fly...

[deHarro]

Ok, got a serial port spy up and running... I send consecutive jog commands and when releasing the knob of the joystick, one or two 0x85 are issued:

So far I'm confident, that the culprit lies somewhere in GRBL-Plotter.

Perhaps you managed to deal all well on the listening port from the joystick, but forgot to handle the bypassing on the sending port to GRBL?

[svenhb]

I need to check this evening...

But how sure are you, that 0x85 chars are transmitted asynchronously and bypassing the already ampled strings (or string parts)? At least the 0x85 are shown in the DIY-control window, with explanation text?

[deHarro]

Hi Sven, is "At least the 0x85 are shown in the DIY-control window, with explanation text?" in the comment above a question from you to me?

If so, no, I do not see any "0x85 with explanation" in the DIY window.

Here is what I get:

This is directly after closing/opening both ports (to clear the windows) and performing a short positive X move with the joystick.

Now again a short move in positive X:

You see, there is a "?" in front of the first jog command of this second move. And you see, this "?" is echoed to GRBL in front of the next jog command to GRBL, too! (You can count the jog commands in both pictures to verify this)

[edit] I see a "?" in front of all commands in both windows. I checked this with the serial spy tool: Joystick is not sending any character before the first jog command ($J=G91X...). [/edit]

[svenhb]

I mean your post 2hours ago: "I send consecutive jog commands and when releasing the knob of the joystick, one or two 0x85 are issued" When you send 0x85 do see it in the DIY-control window?

[deHarro]

No, I see only my jog commands and those "?" characters.

[svenhb]

The '?' characters matches with your Jog-Stop command?

[deHarro]

I would say yes. I cannot be sure, but from the pictures I provided you with, one can imagine this. In the spy tool picture you see "85" at this points.

[svenhb]

New try: https://github.com/svenhb/GRBL-Plotter/blob/master/GRBL-Plotter_1205_test.zip

[deHarro]

Hi Sven, no "?" any more in the in-/output, you now issue a "0x3F Status Report Query" in both log windows.

Hopefully this leads us to a solution, but just now the jog commands are still not cancelled.

0x3F is not what I send, I send 0x85 (actually I use "Serial.write(133);" in my code).

So, where does this 0x3F Status Report Query come from?

[svenhb]

Try to send another realtime command below 0x85, like '!' or '~'. What happens then? Perhaps you need to enable your 7th bit to send? (I know doesn't match with 0x85 <-> 0x3F)

[svenhb]

"0x3F Status Report Query" perhaps you really send '?' by mistake?

[deHarro]

0x3F is all 7 bits set. My hardware sends all bits, see the output of the serial spy tool:

Since I send 133 and the tool displays 85 I suppose, that's correct.

I will send some other codes and report...

[svenhb]

Possible real time comands I forward as real time command, (in addition to >0x7F) are 0x18, '?', '~', '!'

[deHarro]

Ok, I will try first with "!"

[edit] When I send "Serial.write('!');" you receive 0x21:

perfect so far... I now use the same procedure to send 0x85. ... This results in 0x3F. Mhmm... "~" is 0x7E... is displayed as "< 0x7E Cycle Start / Resume" in the DIY port listbox ... I send 133 from the joystick and record the readings of my COM port 14 with "Termite":

So I would say, my Arduino sends all codes with 8 bit.

[svenhb]

ok, now I convert unicode to byte - hope is now reading correct values: https://github.com/svenhb/GRBL-Plotter/blob/master/GRBL-Plotter_1206_test.zip

[deHarro]

I'm sorry, still 0x3F

[deHarro]

Hi Sven, did you encounter the following source: SerialPort Encoding

In short: "You have two options; one would be to use the API’s that deal with byte[] and bypass the Encoding, or to use the correct Encoding. However finding the correct encoding is a bit tricky..."

[svenhb]

No, i didn't know, I will check. I started with the function "serialPort.ReadTo("\r\n");" which is used in the other serial-windows. But with this I can't filter the real time command. Then I switched to "serialPort.ReadExisting()" (returning a string) but, as we figured out, chars above 0x7F are a problem. Next try is "SerialPort.Read" which fills a byte-array. I hope this solves the problem (tomorrow).

[svenhb]

Tried "SerialPort.Read": https://github.com/svenhb/GRBL-Plotter/blob/master/GRBL-Plotter_1207_test.zip Hope is fixed now...

[deHarro]

Hi Sven, I think, we are nearly through :-)

All jog commands are processed (green arrows) AND the jog-cancel command overtakes all pending jog commands (red arrow right to left). Fine so far:

Your port now recognizes characters greater than 0x7F and forwards them to GRBL (as far as I interprete the output of both listboxes).

Only GRBL doesn't stop immediately but continues to move til the end of the issued jog commands.

So I think, now you have to look at the sending side aimed at GRBL. Perhaps you have to flush (or delete or better clear) the output queue of GRBL-Plotter(!) instantly after fordwarding the 0x85 to GRBL?

[svenhb]

Too bad... I found also another problem: jogging during pause of a stream doesn't work anymore... You could follow this, to avoid sending too much jog-commands: https://github.com/gnea/grbl/wiki/Grbl-v1.1-Jogging#how-to-compute-incremental-distances

[deHarro]

This would solve a part of the problem, but as far as I understand jogging, GRBL is able to abort even jog commands underway (say I issue $J=G91X100F100, this will take some time before reaching the endpoint). If GRBL encounters a jog-abort while this said command is executing, it will bring the machine to a halt with deceleration and before the endpoint of this jog command is reached.

Is this possible alone by avoiding too much jog commands? Ok, I will try this. But I fear, it will take some time until I'm at that point :-)

By the way, I hope you get the problem with jogging in stream pauses solved!

[svenhb]

Problem solved, 0x85 will also clear my internal buffer https://github.com/svenhb/GRBL-Plotter/blob/master/GRBL-Plotter_1208_test.zip

[deHarro]

Hi Sven, seems to work flawlessly, very fine!

I'm on implementing the math for step size, speed and proper command frequency according the joystick throw. Hope the AtMega is fast enough...

[papillion47]

Ben acemi bir CNC ve GRBL kullanıcısıyım. İlk başta bana önerilen linkten GRBL yi yükledim. Ve wiki sayfalarından öğrenerek tüm ayarları doğru şekilde yaptım. Vectric Aspire de hazırladığım tap uzantılı işlerimi gayet sağlıklı olarak birkaç yıldır yapmaktaydım. Geçenlerde ne olduysa visualizer ve heightmap çalışmamaya, ekranda hiçbir şey göstermemeye başladı. GRBL yi defalarca silip yeniden yüklemek fayda etmedi. İnternetten bularak GRBL benzeri olan Candle programı yükledim. o zaman da visualizer çalıştı fakat bu defa manuel kumanda ettiren jog komutları aktif olmadı. O komutları kullanmadan gereken spindle yeri ayarları yapılamıyor. Bu konuda bir yardımı olacak çıkarsa çok mutlu olacağım. Aşağıda son ayarlanan durum ekranımı veriyorum. Teşekkürlerimle..

[svenhb]

What do you get if you enable "Show real time status report", before connecting the controller? Should look like this:

[papillion47]

Benim grbl de böyle bir seçenek yok.

[svenhb]

You should use latest release of GRBL-Plotter: https://github.com/svenhb/GRBL-Plotter/releases