grblHAL / Templates

grblHAL template code and plugin examples
Other
8 stars 2 forks source link

HPGL Interpreter Flow Control #2

Open Joey-Orduna opened 2 years ago

Joey-Orduna commented 2 years ago

Hi. I've been trying to use the HPGL interpreter to run a cutting plotter, but I'm having trouble figuring out how to send commands to it.

I've compiled the plugin and have verified this by the message "Motori HPGL v0.03" after sending the "$HPGL" command via serial, however there are no feedback messages after sending any other commands while it's in this state. I'm able to switch back to the gcode interpreter with the "+" command. Is the streaming protocol different than the gcode interpreter? Because my understanding is that the stream gets redirected via function pointers... but I'm still learning the grblHAL architecture.

I would appreciate it if you could give me a little more insight on how to properly use this plugin.

terjeio commented 2 years ago

Is the streaming protocol different than the gcode interpreter?

Yes - and there is no feedback after each command. I have tried to use the XON/OFF protocol for handshaking but could not make it work (on Win7/WIn10) as it seems to beeing not implemented at the driver level on the PC side. RTS/CTS handshaking might be possible, at least for some of the grblHAL drivers that use "native" USB, providing that the MCU USB code supports that.

What I ended up with is querying the buffer state with ESC . B (as defined for HP7475A plotters):

The Output Buffer Space Instruction, ESC . B The output buffer space instruction, ESC . B, outputs the plotter’s available buffer space. This instruction is used in a software checking handshake to interrogate the plotter regarding available buffer space. No parameters are used. RESPONSE

The plotter’s response is a decimal number in the range 0 to 1024, and represents the number of bytes of buffer space currently available for storing graphic instructions sent from the computer. TERM This decimal number is followed by the output termina¬ tor which defaults to carriage return, CR, or is as set by ESC . M.

I have written a simple C# program that uses ESC . B for handshaking, and there is a Python program available here that does the same. I can make my C# program available, but it needs a bit of polishing first...

I would appreciate it if you could give me a little more insight on how to properly use this plugin.

After entering HPGL mode the controller should work as a normal HPGL plotter, simple as that.

To make use of the front panel buttons on my C.ITOH plotter I added plugin code for the PI Pico driver, such code is optional and a similar plugin can be added for other plotters/grblHAL drivers as needed.

Joey-Orduna commented 2 years ago

Thank you for this helpful information! I'm trying to interface a plotter to existing plotter software, since it handles the drag knife offsets as well as other parameters for different materials.

I've been using a little script that parses the HPGL and converts it to g-code, it only adds the drag knife offsets though and is limited in functionality and performance.

This little plugin was exactly what I needed!

just-jason commented 1 year ago

RTS/CTS handshaking might be possible, at least for some of the grblHAL drivers that use "native" USB, providing that the MCU USB code supports that. .... ...

I have written a simple C# program that uses ESC . B for handshaking, and there is a Python program available here that does the same. I can make my C# program available, but it needs a bit of polishing first...

I have been doing some tests on the Pico with its native USB CDC connection. It looks like there should be a possibility to use flow control on the USB CDC port of the Pico. Would it be possible to have this as option as it would make sending files much easier and more reliable. https://raspberrypi.github.io/pico-sdk-doxygen/grouphardwareuart.html#ga54a9e298ebec96510e324bbab01247c7

terjeio commented 1 year ago

@just-jason The link you provided is for UART comms, not USB. UART HW flow control will require a designated handshake pin and an external UART/USB bridge capable of handling the handshake signal (my FTDI breakout can do that). For the native USB connection handshaking has to be performed entirely in software - the CDC protocol allows that, but I have not looked into how to implement it and I do not know if the USB stack used by the Pico has the neccessary protocol support.

terjeio commented 1 year ago

I've found some info related to RP2040 that might be promising:

One is this TinyUSB pull request that implements CH341 emulation that includes RTS handling. Another is this issue which is related to handshaking, if this is usable depends on the host USB driver - seemingly the Windows driver does not handle this well according to the pull request readme.

I have just received a couple of Pi Pico W boards, when I get time I will look into handshaking again as well as attempt to add telnet/websocket support over WiFi. It could well be that handshaking is inherent in the telnet/websocket protocols - but I have not tested that yet...

just-jason commented 1 year ago

Thank you very much for looking into this.

terjeio commented 1 year ago

FYI I have switched to a FTDI USB <> UART breakout board and added physical RTS handshaking. Running a test now with a large file and that seem to work as it should.

I will commit the required changes for this when I have done some more testing.

just-jason commented 1 year ago

That is also a good solution as it would be compatible with non. USB-CDC boards.

terjeio commented 1 year ago

I will commit the required changes for this when I have done some more testing

Committed now for the RP2040, including an update to the hpgl code for trapping more of the device control instructions (ESC . sequences). I have also added an compile time option to rehome the plotter on IN;, default is on.

I do not know if it is the default behaviour for plotters to rehome on IN; - can somebody enligthen me on that?

just-jason commented 1 year ago

I will commit the required changes for this when I have done some m I do not know if it is the default behaviour for plotters to rehome on IN; - can somebody enligthen me on that?

IN does not normally home a plotter. It will usually initialize the device restoring default setting for speed, scale and a few other things. It may be a good idea to add a complie option for home on start as this would be the default method used by plotters