Problem using send.py [SOLVED]

I use skeinforge to slice and want to avoid having to open up the reprap host in order to send gcode to my printer so I wrote a simple batch file wrapper for send.py:
send.bat:

echo %1
C:\Python27\python.exe "C:\Documents and Settings\Greg\Desktop\reprap\skeinforge\fabmetheus_utilities\miscellaneous\fabricate\send.py" -v -p COM3 %1 
pause

I then associated .gcode with the send.bat script so that all I have to do is double click the gcode and it sends it to the printer.
The problem is, when it gets to a gcode that the 5d firmwaare doesn't understand e.g. M103 it just sits there waiting to get an ok from the printer, but that never comes and it stops at that point.
I tried using replace.csv to replace M103 and M101 codes with a comment ";", but send.py still seems to wait after sending the comment. It gets this far and then stops:

C:\Documents and Settings\Greg\Desktop\reprap\models>echo "C:\Documents and Sett
ings\Greg\Desktop\reprap\models\disc_export.gcode"
"C:\Documents and Settings\Greg\Desktop\reprap\models\disc_export.gcode"

C:\Documents and Settings\Greg\Desktop\reprap\models>C:\Python27\python.exe "C:\
Documents and Settings\Greg\Desktop\reprap\skeinforge\fabmetheus_utilities\misce
llaneous\fabricate\send.py" -v -p COM3 "C:\Documents and Settings\Greg\Desktop\r
eprap\models\disc_export.gcode"
You have requested that verbosity be set to True
All communication with the arduino will be printed
Arduino port set to COM3
Opening serial port: COM3
Serial Open?: True
Baud Rate: 19200
Resetting arduino...
< start
> G21
< ok
> G90
< ok
> T0
< ok
> M104 S205
< ok
> G92 E0
< ok
> G1 Z8.0 F50
< ok
> G28 Y0
< ok
> G28 X0
< ok
> G1 X122.0 F3000
< ok
> G28 Z0
< ok
> G92 Z0
< ok
> G1 Z8.0 F50
< ok
> M109 S205
< ok
> M113 S0.75
< ok
> G92 E0
< ok
> G90
< ok
> G21
< ok
> ;

I next tried to just manually remove the ";"
This is the output I get when running the program:

C:\Documents and Settings\Greg\Desktop\reprap\models>echo "C:\Documents and Sett
ings\Greg\Desktop\reprap\models\disc_export.gcode"
"C:\Documents and Settings\Greg\Desktop\reprap\models\disc_export.gcode"

C:\Documents and Settings\Greg\Desktop\reprap\models>C:\Python27\python.exe "C:\
Documents and Settings\Greg\Desktop\reprap\skeinforge\fabmetheus_utilities\misce
llaneous\fabricate\send.py" -v -p COM3 "C:\Documents and Settings\Greg\Desktop\r
eprap\models\disc_export.gcode"
You have requested that verbosity be set to True
All communication with the arduino will be printed
Arduino port set to COM3
Opening serial port: COM3
Serial Open?: True
Baud Rate: 19200
Resetting arduino...
< start
> G21
< ok
> G90
< ok
> T0
< ok
> M104 S205
< ok
> G92 E0
< ok
> G1 Z8.0 F50
< ok
> G28 Y0
< ok
> G28 X0
< ok
> G1 X122.0 F3000
< ok
> G28 Z0
< ok
> G92 Z0
< ok
> G1 Z8.0 F50
< ok
> M109 S205
< ok
> M113 S0.75
< ok
> G92 E0
< ok
> G90
< ok
> G21
< ok
> M105
< ok T:193 B:193
> M113 S1.0
< ok
> M108 S26.0
< ok
> M104 S195.0
< ok
> M108 S15.6
< ok
> G1 X87.14 Y47.15 Z0.2 F575.999
< ok
> G1 F11400.0
< ok
> G1 E12.0
< ok
> G1 F575.999
< ok
> G92 E0
< ok
> G1 X87.14 Y62.85 Z0.2 F575.999 E25.529
< ok
> G1 X102.86 Y62.85 Z0.2 F575.999 E51.058

And when it gets to the end, it just stops.
The full gcode I am trying to send is here: [pastebin.com]
It is just a simple disc on a single layer with an outline created using Lenbok's outline plugin.
Sending the same gcode using the reprap host works fine.

Am I doing something wrong with my use of send.py? Is anyone able to successfully print using send.py? Anything else you can think of that I can try?

Edited 2 time(s). Last edit at 12/27/2010 10:01PM by Greg Frost.

I gave up on send.py and wrote send-gcode: [forums.reprap.org]

I changed the firmware (FiveD_GCode_Interpreter 20100806) in the Sanguino in my Mendel so that it replies to M101 and M103 with 'ok' rather than an error message. I did this by making the following changes in the file 'process_g_code.pde'

Original:

/*
//turn extruder on, forward
case 101:
ex[extruder_in_use]->setDirection(1);
ex[extruder_in_use]->setSpeed(extruder_speed);
break;

//turn extruder on, reverse
case 102:
ex[extruder_in_use]->setDirection(0);
ex[extruder_in_use]->setSpeed(extruder_speed);
break;

//turn extruder off

*/

Changed to:

//turn extruder on, forward
case 101: /* null code so that skeinforge output can be used easily FD */
/*ex[extruder_in_use]->setDirection(1);
ex[extruder_in_use]->setSpeed(extruder_speed);*/
break;

//turn extruder off
case 103: /* null code so that skeinforge output can be used easily FD */
/*ex[extruder_in_use]->setDirection(0);
ex[extruder_in_use]->setSpeed(extruder_speed);*/
break;

Unless code execution time or code space is extremely tight, this seems like a low risk change. This has allowed me to use send.py with no complications. I hope that this helps.

fdavies

Oh, some more things:

In the file 'process_g_code.pde' you can turn on an echo by changing line 95 from "
byte SendDebug = DEBUG_INFO | DEBUG_ERRORS;" to "byte SendDebug = DEBUG_ECHO | DEBUG_INFO | DEBUG_ERRORS;". When I did this (recompiling and downloading the firmware into the sanguino, of course), I could see what the Sanguino was receiving on its serial port from send.py. You would have to undo this change after you have finished debugging, of course.

By doing this I discovered that send.py was removing the spaces in the commands, which changed "G1 X0 Y0" to "G1X0Y0" which the firmware did not seem to like.

I fixed this by commenting out the following line in the file 'RepRapArduinoSerialSender.py' at approximately line 96

#block=block.replace(' ','')

This line is what takes out the spaces.

fdavies

another option is to send a generic code that sends a reply back

change/replace.csv file M101,M103 to M105 - this code sends you back the temp value and sends an ok.

lines with no data seem to cause the firmware to hang.

nothing to reply to gets no reply, no reply gets no new command.

I wish that the firmware was an aggressive. meaning that it ensured conversation, and assumed someone was there to talk to it, and kept talking till told to be quiet. we have a passive host and a passive firmware. not much for talking, either one of them!

In a general sense, the host must wait for an OK, as that's what we're using to ensure that the host doesn't overrun the firmware's recieve buffer - dropping a command will cause a flawed print, and may cause a failed print. Regularly dropping commands would be guaranteed to cause a failed print.

So flow control is needed.

It seems like the firmwares should be required to ALWAYS send a response after every line, even if it's blank or invalid. A simple "ok" for a blank line, maybe a "huh? ok" for an invalid/not recognized command's not an unreasonable requirement... Don't know how to make that change with this particular firmware off the top of my head though. Probably add a "default" case to the bottom of the list, that simply sends a "huh? " (with no line feed) and the ok is probably already handled.

---

--
I'm building it with Baling Wire

fdavies and jamesdanielv: Awesome thanks.

I now have this in my replace.csv:

M101	M105;
M103	M105;
M108	M105;

and I modified RepRapArduinoSerialSender.py as follows:

		block=block.replace(' ','')
		block=block.replace("\t",'')

becomes:

		block=block.replace("\t",' ')

This works great. It is fantastic not having to go through 20 mouse clicks to start a print.

Edited 2 time(s). Last edit at 12/28/2010 06:19PM by Greg Frost.