Problems sending Gcode using HTTP GET to RRF3 RC2

[gradu6]

Hello, I made an excel program to send custom Gcode to RRF3 RC2 using constructs like:

http://192.168.1.127/rr_gcode?gcode=M572 D0 G90 G1 X20 Y45 F6000 G1 Z0.5 F300 G91 G1 X2.5 F1200 E2.5 G1 X17.5 F1200 E0.73 G1 X9 F6000 E0.37 G1 X1 F6000 E0.04 G1 X10 F1200 E0.42 G1 X20 F6000 E0.83 G1 X20 F1200 E0.83 G1 X30 F6000 E1.25 G1 X30 F1200 E1.25

http://192.168.1.127/rr_gcode?gcode=G1 X10 F1200 E0.42 G1 X0.5 F1200 E-2.5 G1 X9.5 F1200 E0 G3 Y20 J10 F1200 E0 G1 X-160 F6000 E0 G3 Y-20 J-10 F1200 E0 G0 Z0.2 F300 G1 X2.5 F1200 E2.5 G1 X17.5 F1200 E0.73 G1 X10 F6000 E0.42 G1 X10 F1200 E0.42

http://192.168.1.127/rr_gcode?gcode=G1 X20 F6000 E0.83 G1 X20 F1200 E0.83 G1 X30 F6000 E1.25 G1 X30 F1200 E1.25 G1 X10 F1200 E0.42 G1 X0.5 F1200 E-2.5 G1 X9.5 F1200 E0 G3 Y20 J10 F1200 E0 G1 X-160 F6000 E0 G3 Y-20 J-10 F1200 E0

The gcode line separator is the character: vbLF = Chr(10)

The issue is that it works when send in smaller chunks but when sent quickly, even the response is a OK between them, the execution of the gcode is faulty. (does not execute completely or even executes wrong moves, at wrong speeds)

Is sending Gcode through HTTP GET able to function correctly at this time in RRF3 RC2? From my numerous attempts, I found that it probably cannot work reliably.

[zombiRon]

the max length for a HTTP URL is 2000 characters, I think you may be hitting the limit??

as excel uses the IE engine for HTTP transfer...

https://support.microsoft.com/en-gb/help/208427/maximum-url-length-is-2-083-characters-in-internet-explorer

[gradu6]

Hi, Thanks for answering so quickly. In my subroutine I check when the length of Gcode reaches 200 characters, and then I send it

using an object: Set oRequest = CreateObject("WinHttp.WinHttpRequest.5.1")

http://192.168.1.127/rr_gcode?gcode=M572 D0 G90 G1 X20 Y45 F6000 G1 Z0.5 F300 G91 G1 X2.5 F1200 E2.5 G1 X17.5 F1200 E0.73 G1 X9 F6000 E0.37 G1 X1 F6000 E0.04 G1 X10 F1200 E0.42 G1 X20 F6000 E0.83 G1 X20 F1200 E0.83 G1 X30 F6000 E1.25 G1 X30 F1200 E1.25

Then I check the answer to be .StatusText = "OK" and the .ResponseText is a JSON construct showing how many characters are available in RRF3 RC2 (web server?). (and always shows characters remaining) After that the excel vba code sends another chunk of gcode as I show above and so on. At all points, RRF2 RC2 responds with OK. Therefore I think the transmission to RRF2 RC2 is fine, the reception of all above GCODE is fine (all three transmissions as shown in my first post above) However, the execution is not OK, the movements just stop or wrong moves at low speeds are happening when trying to transfer all three sections of gcode shown above.

[zombiRon]

In that case, I'd say that RRF buffer is not able to handle that amount of data. The OK isn't indicative of all the code being executed. It's a response that the message was received by the webserver.

This behaviour your observing smells like buffer overflow, erratic movement and out of order execution of instructions is a characteristic of buffer overflow in any microprocessor based system.

Remember this way of sending G-Code is a convenience function to be used like the console in DWC for simple lines of code as I understand it.

Larger routines should be run from the SDCARD so that RRF can manage how much data if fetches from the file into the planning buffer.

I may be wrong here, so best wait for DC42 or someone from the firmware team to respond.

I did write a bridge app to handle output from LightBurn on a pseudo USB port and I stream that to RRF via the telnet interface, I think VB has a function to open a TCP port and stream data, maybe this would be a better approach??

[dc42]

GCodes received by HTTP are stored in a buffer. The JSON reply to the rr_gcode commands includes item "buff" which tells you the number of characters available in the buffer. So next time you send a command via rr_gcode, don't send more than that number of characters. If you just want to read the amount of buffer space, use rr_gcode with an empty gcode argument. See the code at HttpResponder.cpp lines 527-537.

[gradu6]

Thank you for the quick and effective help. Yes, it works now. There are no more strange moves or slow speed strange moves.

==== Hello dc42,

1. Please let me know a PayPal address i could use for a small donation to the people that made the duet3d electronics, firmware and the duet web server

2. The excel sheet and code might be useful to others, please let me know where is best to make it available when is polished enough (and documented) to be useful. (Each Gcode instruction is held in a cell, all sequences have a single column that ends in a blank cell. On a single excel sheet you can have multiple separate sequences - can be thought as different adjustable Gcode macros. The Gcode is constructed in formulae using different adjustable parameters like speed, overextrusion %, X, Y, Z and so on... I think is a very flexible way of experimenting with 3D printers and their required adjustments. Sending it over WiFi with no cables makes it even nicer.)

What it does in short: L1- Reads the Gcode to be sent from the current Excel row, held in a cell from a given single excel column and place it in variable vCell.

L2- Check with a Http Get of this kind: "http:///rr_gcode?gcode=" if the response is OK then assign to vBuf variable the JSON buffer size reported back.

L3- If the vBuf > len(vCell)+5 (5 was arbitrary chosen), goto L4 -else- wait 250ms and goto L2

L4- Send with a Http Get the Gcode from vCell with a Http Get like: "http:///rr_gcode?gcode=" & vCell if the response is OK then assign to vBuf variable the JSON buffer size reported back.

L5- increment the excel row and if empty goto L7 -else- goto L6

L6- Read the Gcode to be sent from the current Excel row, and place it in variable vCell. then goto L3

L7 -finish