Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HPGL Interpreter Flow Control #2

Open
Joey-Orduna opened this issue Mar 26, 2022 · 10 comments
Open

HPGL Interpreter Flow Control #2

Joey-Orduna opened this issue Mar 26, 2022 · 10 comments

Comments

@Joey-Orduna
Copy link

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
Copy link
Contributor

terjeio commented Mar 26, 2022

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
Copy link
Author

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
Copy link

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/group__hardware__uart.html#ga54a9e298ebec96510e324bbab01247c7

@terjeio
Copy link
Contributor

terjeio commented Aug 15, 2022

@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
Copy link
Contributor

terjeio commented Aug 26, 2022

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
Copy link

Thank you very much for looking into this.

@terjeio
Copy link
Contributor

terjeio commented Sep 28, 2022

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
Copy link

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

@terjeio
Copy link
Contributor

terjeio commented Sep 29, 2022

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
Copy link

just-jason commented Sep 29, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants