Sailfish 7.7 serial connection only executes first command?

[dennisdevulder]

Hi there,

After playing around with GPX and setting up a serial connection to my FlashForge Creator Pro it seems that it only executes the first command.

here's an example:

// test.gcode
M70 P5 ( We <3 Making Things!)
M72 P1  ( Play Ta-Da song )

When running:

./gpx -vgps -m r1d test.gcode /dev/tty.usbmodem* 

it only shows the "We <3 making things" message and then exits.

However when I do:

./gpx -vgp -m r1d test.gcode test.x3g

And put on the SD card it works fine.

Any ideas on how to fix it?

[dcnewman]

I believe the serial support in GPX is only intended to send a single command. It is definitely not intended to send an entire print file. Henry started writing it for purposes of reading/writing EEPROM settings. I do not know if he ever finished even that.

[dennisdevulder]

Hi dcnewman,

Thank you for your fast reply.

I am currently trying to build a web interface allowing me to upload an STL file and Slice it appropriate to the type of printer connected and print it.

As the sailfish 7.7 firmware requires an x3g file to print I was wondering if you have an idea of how I can send the x3g file through my USB serial connection. After all it's just information interpreted on the printer right?

With kind regards,
Dennis

[markwal]

After all it's just information interpreted on the printer right?

It is, but serial communication is trickier than that. There's a call and response protocol with checksums and repeats that you have to write code for. That's the bit that is relatively, uh, fresh (ie not mature) in the GPX code base and as Dan said, not really intended for printing a whole file.

There's an s3g protocol handler written in python here: https://github.com/makerbot/s3g, but makerbot isn't opensource any more so while you may be able to get it to work, I'm not sure how much community support there is if you need help.

https://github.com/AstroPrint/AstroBox is a webserver that can talk s3g. I think Daniel used the s3g python module I mentioned before as a starting point.

And there's also my OctoPrint (https://github.com/markwal/OctoPrint-GPX) plugin that does something similar and I did it by forking GPX and wrapping the serial protocol bits to give back "RepRap" style serial responses to OctoPrint.

But all that said, USB printing isn't ideal because even when it is "working", it causes small pauses because of the serial communication overhead or large pauses if the host gets busy and doesn't keep the movement queue full. This will result in blobs and gaps in the result. The SailFish docs talk about it here: http://www.sailfishfirmware.com/doc/tuning-slicer-calibration.html#x27-690005.1.2

[dcnewman]

Unfortunately it's not very simple. You should start by reading the s3g/x3g spec,

https://github.com/makerbot/s3g/blob/master/doc/s3gProtocol.md

You'll quickly see that the on-wire format is different from the file format. Yes, really dumb.
Don't blame me. While you can use my branch of GPX to generate an output file with the on-wire
format, you cannot just blast that over USB. The protocol is a command/response protocol with
implicit flow control: implicit in that you don't send the next command until you've gotten the
response to the current one. And based upon the response, you may need to take an alternate
action (resend, abort, ignore, etc.). Worse yet, MBI's firmware has commented out the code to
send any form of error response which leaves the sending code seeing a timeout waiting for a
response and then just attempting a resend without knowing what is happening. Sailfish has
that code NOT commented out and as such when testing with Sailfish, you can actually receive
error responses. (If you're sending well formed s3g/x3g, then you usually don't see any errors
except when sync'ing up at the start of a connection.)

Your best bet is to look at the work done by Mark Walker for octoprint or the Astroprint
folks for Astroprint (a fork of octoprint). Or, you can briefly install MakerWare and look
at the Python code it installs. That code (which I actually did some minor work on back in
early 2012 for MBI), include code to send x3g data over USB.

Further notes, Mark mentioned

There's an s3g protocol handler written in python here: https://github.com/makerbot/s3g

Note that that is old code and has known bugs. I know of one significant fix needed if you use it -- the fix to make it not fail when it receives an error response from the bot.

Dan

[dennisdevulder]

Hi guys,

Thank you so much for the in-depth explanations.
I will check out the other repositories and make the requirements fit my own project.

With kind regards,
Dennis

[tx0h]

hi,

i ran into the same problem. only the first command got
transmitted to my device. it stuck in this loop:

5247                 // first read
5248                 for(;;) {
5249                     // read start byte
5250                     if((bytes = read(sio->port, gpx->buffer.in, 1)) == -1) {
5251                         return errno;
5252                     }
5253                     else if(bytes != 1) {
5254                         return ESIOREAD;
5255                     }
5256                     // loop until we get a valid start byte
5257                     if(gpx->buffer.in[0] == 0xD5) break;
5258                 }

in the port_handler(). it didn't got the exit (0x5D). because
0xD5 might be 216 or -43 (in our case the char will be -43)
we need to handle signed/unsigned char adequately.
we can meet the requirements by adding the -funsigned-char parameter to
the gcc compiler. like this:

diff --git a/Makefile b/Makefile
index 0ac09f4..4035876 100644
--- a/Makefile
+++ b/Makefile
@@ -1,5 +1,5 @@
# Declaration of variables
-CC = cc
+CC = cc -funsigned-char
CC_FLAGS = -w
L_FLAGS = -lm

hope, i'm not to late and others will benefit from my tip, hidden
in a response of a dated issue report :-) maybe it's worth to
add this patch to the project. other solutions are possible,
when one is willing to change the code.

with this patch it should be possible again to use gpx in a
pipe as follows:

echo "G28 X0 Y0" | gpx -s -i /dev/ttyXXXXX

this will read gcode from stdin and outputs it to the device.

greetings,
tx

[markwal]

Yeah. My fork just added the cast to unsigned char. This (original) fork is a few years fallow. Current development here: http://github.com/markwal/GPX. Also added a GUI and an installer for Windows: http://markwal.github.io/GpxUi.