ReplicatorG for FiveD-style firmwares, testers requested
149 views
Skip to first unread message
Ben Jackson
Apr 4, 2011, 2:36:38 PM4/4/11
to MakerGear - Make Today, Change Tomorrow
Over the weekend I got ReplicatorG printing on my Prusa using Gen6
with a "stock" FiveD firmware (rebuilt for higher baud rate and other
tuning). I believe I have eliminated the hangs and retransmit
problems. I have also improved the Control Panel behavior (especially
for firmware that supports M114). I have even used it to flash
firmware on my board. There's some evidence that it also works on
Teacup and I made some effort to inspect the Tonokip and Kilmentkip
firmware source for compatibility as well.
Known issues:
* On firmware without M114 (that returns "C: ...", so not Teacup) the
control panel will think it is at 0,0,0 and will make a (possibly
disastrous) absolute move when you hit a jog button.
* Extrude for time works but once started cannot be stopped. I have
added code to recover from you hitting "reset" on the fw, though.
* The realtime feedrate/travel multipliers are reversed (I have a fix
but have not tested it yet).
* I have seen builds fail to start with "parser is null" which may be
an artifact of my build environment and goes away with a restart.
Binary distributions are at: http://ben.com/reprap/ (with the odd
version 00245 which was meant to be 0024_5d). I have added two
machine types: "RepRap5d (76800 Baud)" and "Teacup 115200 Baud)".
Teacup has a slightly different "resend" protocol than every other
firmware I've checked, so choose the right one. I recommend 76800
baud as a max with "FiveD" because otherwise retransmits go through
the roof (probably due to the fw losing characters in the serial
handling). You can adjust the baud in machines/reprap.xml though.
DON'T JUST USE THE "TEACUP" ONE for the baud because it is not the
same.
If you have problems, please edit machines/reprap.xml and increase the
"debugLevel" to 2 or so and cut-and-paste the log messages for me.
Especially if you see a hang.
The source is on github: https://github.com/bjj/ReplicatorG
--
Ben Jackson AD7GD
<b...@ben.com>
http://www.ben.com/
with a "stock" FiveD firmware (rebuilt for higher baud rate and other
tuning). I believe I have eliminated the hangs and retransmit
problems. I have also improved the Control Panel behavior (especially
for firmware that supports M114). I have even used it to flash
firmware on my board. There's some evidence that it also works on
Teacup and I made some effort to inspect the Tonokip and Kilmentkip
firmware source for compatibility as well.
Known issues:
* On firmware without M114 (that returns "C: ...", so not Teacup) the
control panel will think it is at 0,0,0 and will make a (possibly
disastrous) absolute move when you hit a jog button.
* Extrude for time works but once started cannot be stopped. I have
added code to recover from you hitting "reset" on the fw, though.
* The realtime feedrate/travel multipliers are reversed (I have a fix
but have not tested it yet).
* I have seen builds fail to start with "parser is null" which may be
an artifact of my build environment and goes away with a restart.
Binary distributions are at: http://ben.com/reprap/ (with the odd
version 00245 which was meant to be 0024_5d). I have added two
machine types: "RepRap5d (76800 Baud)" and "Teacup 115200 Baud)".
Teacup has a slightly different "resend" protocol than every other
firmware I've checked, so choose the right one. I recommend 76800
baud as a max with "FiveD" because otherwise retransmits go through
the roof (probably due to the fw losing characters in the serial
handling). You can adjust the baud in machines/reprap.xml though.
DON'T JUST USE THE "TEACUP" ONE for the baud because it is not the
same.
If you have problems, please edit machines/reprap.xml and increase the
"debugLevel" to 2 or so and cut-and-paste the log messages for me.
Especially if you see a hang.
The source is on github: https://github.com/bjj/ReplicatorG
--
Ben Jackson AD7GD
<b...@ben.com>
http://www.ben.com/
Rick Pollack
Apr 4, 2011, 11:42:04 PM4/4/11
to make...@googlegroups.com
That's great Ben! I'd like to get with the program and have standard firmware that can pushed out by RepG. Getting there...
Rick
Rick
tinyenormous
Apr 5, 2011, 12:43:29 AM4/5/11
to MakerGear - Make Today, Change Tomorrow
Hi Ben!
This is what I'm getting. I have a 168 with absolutely nothing
attached to it, and teacup freshly uploaded with bangbang enabled.
otherwise stock.
[22:37:13] Got name ascii
[22:37:13] Parsed object name[ascii] facets 5304
[22:37:14] Loading machine: Teacup (115200 Baud)
[22:37:14] Loading simulator.
[22:37:14] Loading driver: replicatorg.drivers.reprap.RepRap5DDriver
[22:37:14] Initializing Serial.
[22:37:14] Sending: N0 M110 *3
[22:37:14] Supports RC
[22:37:14] Supports RC
[22:37:16] RepRap not responding to gcode. Failed to connect.
[22:37:16] Supports RC
[22:38:33] Initializing Serial.
[22:38:33] Sending: N0 M110 *3
[22:38:33] Supports RC
[22:38:36] RepRap not responding to gcode. Failed to connect.
[22:38:36] Supports RC
I'm really excited about this, thanks for your work.
This is what I'm getting. I have a 168 with absolutely nothing
attached to it, and teacup freshly uploaded with bangbang enabled.
otherwise stock.
[22:37:13] Got name ascii
[22:37:13] Parsed object name[ascii] facets 5304
[22:37:14] Loading machine: Teacup (115200 Baud)
[22:37:14] Loading simulator.
[22:37:14] Loading driver: replicatorg.drivers.reprap.RepRap5DDriver
[22:37:14] Initializing Serial.
[22:37:14] Sending: N0 M110 *3
[22:37:14] Supports RC
[22:37:14] Supports RC
[22:37:16] RepRap not responding to gcode. Failed to connect.
[22:37:16] Supports RC
[22:38:33] Initializing Serial.
[22:38:33] Sending: N0 M110 *3
[22:38:33] Supports RC
[22:38:36] RepRap not responding to gcode. Failed to connect.
[22:38:36] Supports RC
I'm really excited about this, thanks for your work.
Ben Jackson
Apr 5, 2011, 12:52:57 PM4/5/11
to MakerGear - Make Today, Change Tomorrow
Looks like you hit 'connect' once after an initial failure?
I just pulled out my unusual Teacup board and the very first time
(when I switched driver from Thing-o-Matic to teacup and reconnected)
I saw your result. When I restarted to turn on debug it started
working. Thereafter I could hit connect/disconnect at will and it
worked fine.
There might be a bug with switching drivers. I'll look into it. For
now can you tell me if it connects after you restart RepG?
(just tried disconnect, set driver to ToM, set driver bad to Teacup,
tried to connect, failed and RepG wedged. Once I killed it and
restarted (now defaulting to Teacup) it worked)
I just pulled out my unusual Teacup board and the very first time
(when I switched driver from Thing-o-Matic to teacup and reconnected)
I saw your result. When I restarted to turn on debug it started
working. Thereafter I could hit connect/disconnect at will and it
worked fine.
There might be a bug with switching drivers. I'll look into it. For
now can you tell me if it connects after you restart RepG?
(just tried disconnect, set driver to ToM, set driver bad to Teacup,
tried to connect, failed and RepG wedged. Once I killed it and
restarted (now defaulting to Teacup) it worked)
t3kboi
Apr 5, 2011, 4:00:31 PM4/5/11
to MakerGear - Make Today, Change Tomorrow
I have found this to be that RepG only parses the .xml file for
machines at startup.
I Can reproduce the connection problem on multiple computers running
WIN7 and RepG 0024. variuos firmwares: Reprap5D, tonokip, tesla,
johnnyr......
Launch RepG - fails to connect to machine.
Exit RepG (Or use task manager to kill javaws.exe if it is locked,
which it does about 40% of the time).
Edit <machines>.xml (whichever machine file you are using - mine is
using the reprap.xml)
Change ANYTHING, and save the changes. (i.e add a space in a comment
line....)
Launch RepG - connection is restored.
Connection capability will remain functional until ANYTHING else
touches the COM port you are using. Then you will have to edit
the .xml file again to restore connectivity.
It seems that RepG only reads the .xml at startup, but seems to load
the previous values if the timestamp wasnt altered.
It should probably re-load the .xml file every time you change drivers
- but it doesnt. You have to exit and restart to see any changes to
the drivers.
machines at startup.
I Can reproduce the connection problem on multiple computers running
WIN7 and RepG 0024. variuos firmwares: Reprap5D, tonokip, tesla,
johnnyr......
Launch RepG - fails to connect to machine.
Exit RepG (Or use task manager to kill javaws.exe if it is locked,
which it does about 40% of the time).
Edit <machines>.xml (whichever machine file you are using - mine is
using the reprap.xml)
Change ANYTHING, and save the changes. (i.e add a space in a comment
line....)
Launch RepG - connection is restored.
Connection capability will remain functional until ANYTHING else
touches the COM port you are using. Then you will have to edit
the .xml file again to restore connectivity.
It seems that RepG only reads the .xml at startup, but seems to load
the previous values if the timestamp wasnt altered.
It should probably re-load the .xml file every time you change drivers
- but it doesnt. You have to exit and restart to see any changes to
the drivers.
tinyenormous
Apr 6, 2011, 12:41:03 AM4/6/11
to MakerGear - Make Today, Change Tomorrow
Hi Ben,
I can't seem to get it to connect no matter what I try. The arduino is
getting data, as I can see the rx light flashing, but it doesn't seem
to be giving repg what it wants in return. Other possibly pertinent
facts:
I am using a seeduino arduino clone (i'll try it on a rbbb in a few
minutes)
I am on a mac.
I can easily connect to and upload to the arduino via the arduino
software.
My arduino still has auto reset enabled. I can disable it with a
switch, so I'll try that as well.
You are correct in reading my log as an attempt to connect after a
failed startup effort.
I'll check back in, in a few.
I can't seem to get it to connect no matter what I try. The arduino is
getting data, as I can see the rx light flashing, but it doesn't seem
to be giving repg what it wants in return. Other possibly pertinent
facts:
I am using a seeduino arduino clone (i'll try it on a rbbb in a few
minutes)
I am on a mac.
I can easily connect to and upload to the arduino via the arduino
software.
My arduino still has auto reset enabled. I can disable it with a
switch, so I'll try that as well.
You are correct in reading my log as an attempt to connect after a
failed startup effort.
I'll check back in, in a few.
tinyenormous
Apr 6, 2011, 12:45:42 AM4/6/11
to MakerGear - Make Today, Change Tomorrow
Partial success!
Disabling auto-reset gives me much more log to look at. does this look
closer to normal?
[22:38:33] Sending: N2 G92 X0 Y0 Z0 E0 *46
[22:38:33] << ok
[22:38:33] FW Accepted: N0 M110 *3
[22:38:33] << rs n0 expected check �
Disabling auto-reset gives me much more log to look at. does this look
closer to normal?
[22:38:33] Sending: N2 G92 X0 Y0 Z0 E0 *46
[22:38:33] << ok
[22:38:33] FW Accepted: N0 M110 *3
[22:38:33] << rs n0 expected check �
tinyenormous
Apr 6, 2011, 12:58:50 AM4/6/11
to MakerGear - Make Today, Change Tomorrow
hmmmm...
Somehow the log got cut off. I'll try again, and if that fails, I'll
post it to a dropbox somewhere.
[22:56:29] resend for line 0 not in our buffer. Resuming from 2
[22:56:29] Resending: "N1 M110*34". Resends in 10 of 0 lines.
[22:56:29] Sending: N1 M110*34
[22:56:29] Resending: "N2 G92 X0 Y0 Z0 E0 *46". Resends in 11 of 0
lines.
[22:56:29] Sending: N2 G92 X0 Y0 Z0 E0 *46
[22:56:29] << ok
[22:56:29] FW Accepted: N1 M110*34
[22:56:29] << ok
[22:56:29] FW Accepted: N2 G92 X0 Y0 Z0 E0 *46
[22:56:29] << ok
[22:56:29] Received OK with nothing queued!
[22:56:29] << ���start
[22:56:29] Sending: N0 M110 *3
[22:56:29] Sending: N1 G90 *49
[22:56:29] Sending: N2 G92 X0 Y0 Z0 E0 *46
[22:56:29] << ok
[22:56:29] FW Accepted: N0 M110 *3
[22:56:29] << ok
[22:56:29] FW Accepted: N1 G90 *49
[22:56:29] << ok
[22:56:29] FW Accepted: N2 G92 X0 Y0 Z0 E0 *46
[22:56:29] << ok
[22:56:29] Received OK with nothing queued!
[22:56:29] << ok�
[22:56:29] Received OK with nothing queued!
[22:56:29] << ok
[22:56:29] Received OK with nothing queued!
[22:56:29] << ok
[22:56:29] Received OK with nothing queued!
[22:56:29] << start
[22:56:29] Sending: N0 M110 *3
[22:56:29] Sending: N1 G90 *49
[22:56:29] Sending: N2 G92 X0 Y0 Z0 E0 *46
[22:56:29] << ok
[22:56:29] FW Accepted: N0 M110 *3
[22:56:29] << rs n0 expected che
Somehow the log got cut off. I'll try again, and if that fails, I'll
post it to a dropbox somewhere.
[22:56:29] resend for line 0 not in our buffer. Resuming from 2
[22:56:29] Resending: "N1 M110*34". Resends in 10 of 0 lines.
[22:56:29] Sending: N1 M110*34
[22:56:29] Resending: "N2 G92 X0 Y0 Z0 E0 *46". Resends in 11 of 0
lines.
[22:56:29] Sending: N2 G92 X0 Y0 Z0 E0 *46
[22:56:29] << ok
[22:56:29] FW Accepted: N1 M110*34
[22:56:29] << ok
[22:56:29] FW Accepted: N2 G92 X0 Y0 Z0 E0 *46
[22:56:29] << ok
[22:56:29] Received OK with nothing queued!
[22:56:29] << ���start
[22:56:29] Sending: N0 M110 *3
[22:56:29] Sending: N1 G90 *49
[22:56:29] Sending: N2 G92 X0 Y0 Z0 E0 *46
[22:56:29] << ok
[22:56:29] FW Accepted: N0 M110 *3
[22:56:29] << ok
[22:56:29] FW Accepted: N1 G90 *49
[22:56:29] << ok
[22:56:29] FW Accepted: N2 G92 X0 Y0 Z0 E0 *46
[22:56:29] << ok
[22:56:29] Received OK with nothing queued!
[22:56:29] << ok�
[22:56:29] Received OK with nothing queued!
[22:56:29] << ok
[22:56:29] Received OK with nothing queued!
[22:56:29] << ok
[22:56:29] Received OK with nothing queued!
[22:56:29] << start
[22:56:29] Sending: N0 M110 *3
[22:56:29] Sending: N1 G90 *49
[22:56:29] Sending: N2 G92 X0 Y0 Z0 E0 *46
[22:56:29] << ok
[22:56:29] FW Accepted: N0 M110 *3
[22:56:29] << rs n0 expected che
Ben Jackson
Apr 6, 2011, 3:37:26 AM4/6/11
to MakerGear - Make Today, Change Tomorrow
The auto-reset can lead to timeouts the first time it tries to connect
because it's waiting for the bootloader to time out and call the real
app. Usually hitting "connect" fixes it, but I may need to increase
the timeout.
I see now that Teacup initializes with "start" + "ok". That extra
"ok" is like saying "ok, I already got that first command, that you
haven't even sent yet..." I didn't run into that when I tried Teacup
earlier tonight because I connected well after the reset.
Can I assume each of those '<< start' lines is you hitting reset? If
so I think you will be able to connect by resetting the board with
RepG disconnected and then hit 'connect' after. I was actually
driving Teacup with RepG earlier (also updated the binaries and pushed
a fix to make the all-relative extruder control work).
I will work on a way to eat that first "ok" after start. If you see
updated binaries at http://ben.com/reprap (newer than this message ;-)
then try them out.
Thanks for the log.
because it's waiting for the bootloader to time out and call the real
app. Usually hitting "connect" fixes it, but I may need to increase
the timeout.
I see now that Teacup initializes with "start" + "ok". That extra
"ok" is like saying "ok, I already got that first command, that you
haven't even sent yet..." I didn't run into that when I tried Teacup
earlier tonight because I connected well after the reset.
Can I assume each of those '<< start' lines is you hitting reset? If
so I think you will be able to connect by resetting the board with
RepG disconnected and then hit 'connect' after. I was actually
driving Teacup with RepG earlier (also updated the binaries and pushed
a fix to make the all-relative extruder control work).
I will work on a way to eat that first "ok" after start. If you see
updated binaries at http://ben.com/reprap (newer than this message ;-)
then try them out.
Thanks for the log.
tinyenormous
Apr 7, 2011, 12:25:38 AM4/7/11
to MakerGear - Make Today, Change Tomorrow
Hi ben!
The last log got cut off, so i have a similar one posted here
http://dl.dropbox.com/u/569387/seeduino%20teacup%20repg.txt
the log shows repg and the arduino talking. I didn't hit anything
except to select the appropriate serial port, then restart repg and
start logging
here is a new log from yesterdays version. A lot of red in that one,
but it still shows as connected.
http://dl.dropbox.com/u/569387/seeduino%20teacup%20repg%20new%20build.txt
i tried it out on a rbbb arduino and a duemilanove 328. I couldn't get
it to connect to the rbbb with or without auto-reset, and I don't want
to cut the trace in order to disable auto reset on the 328 right now.
If i can find my stock diecimillia I will try it on that as well.
Thanks for your hard work.
On Apr 6, 1:37 am, Ben Jackson <b...@ben.com> wrote:
> The auto-reset can lead to timeouts the first time it tries to connect
> because it's waiting for the bootloader to time out and call the real
> app. Usually hitting "connect" fixes it, but I may need to increase
> the timeout.
>
> I see now that Teacup initializes with "start" + "ok". That extra
> "ok" is like saying "ok, I already got that first command, that you
> haven't even sent yet..." I didn't run into that when I tried Teacup
> earlier tonight because I connected well after the reset.
>
> Can I assume each of those '<< start' lines is you hitting reset? If
> so I think you will be able to connect by resetting the board with
> RepG disconnected and then hit 'connect' after. I was actually
> driving Teacup with RepG earlier (also updated the binaries and pushed
> a fix to make the all-relative extruder control work).
>
> I will work on a way to eat that first "ok" after start. If you see
> updated binaries athttp://ben.com/reprap(newer than this message ;-)
The last log got cut off, so i have a similar one posted here
http://dl.dropbox.com/u/569387/seeduino%20teacup%20repg.txt
the log shows repg and the arduino talking. I didn't hit anything
except to select the appropriate serial port, then restart repg and
start logging
here is a new log from yesterdays version. A lot of red in that one,
but it still shows as connected.
http://dl.dropbox.com/u/569387/seeduino%20teacup%20repg%20new%20build.txt
i tried it out on a rbbb arduino and a duemilanove 328. I couldn't get
it to connect to the rbbb with or without auto-reset, and I don't want
to cut the trace in order to disable auto reset on the 328 right now.
If i can find my stock diecimillia I will try it on that as well.
Thanks for your hard work.
On Apr 6, 1:37 am, Ben Jackson <b...@ben.com> wrote:
> The auto-reset can lead to timeouts the first time it tries to connect
> because it's waiting for the bootloader to time out and call the real
> app. Usually hitting "connect" fixes it, but I may need to increase
> the timeout.
>
> I see now that Teacup initializes with "start" + "ok". That extra
> "ok" is like saying "ok, I already got that first command, that you
> haven't even sent yet..." I didn't run into that when I tried Teacup
> earlier tonight because I connected well after the reset.
>
> Can I assume each of those '<< start' lines is you hitting reset? If
> so I think you will be able to connect by resetting the board with
> RepG disconnected and then hit 'connect' after. I was actually
> driving Teacup with RepG earlier (also updated the binaries and pushed
> a fix to make the all-relative extruder control work).
>
> I will work on a way to eat that first "ok" after start. If you see
Ben Jackson
Apr 7, 2011, 3:04:38 AM4/7/11
to MakerGear - Make Today, Change Tomorrow
I think I will be ready to try Teacup printing (not just connecting)
tomorrow. I figured out why I couldn't make it work on my machine
while getting Klimentkip going tonight (currently printing Vica
Illusion from RepG with Kilmentkip).
You are seeing serial problems that I'm not having. There's "Unknown:
[line noise]" in your log, corrupted resend requests, and you're
seeing tons of "start" indicating firmware resets. But the fact that
"ok" and "start" get through means you do have the right baud rate.
And I doubt you're controlling your board over dialup... What
platform are you on? Linux? I wonder if there's some other program
fighting to open your device, changing the parameters, causing RTS to
toggle leading to resets, etc. Perhaps RepG needs to do some kind of
locking it isn't doing?
> The last log got cut off, so i have a similar one posted herehttp://dl.dropbox.com/u/569387/seeduino%20teacup%20repg.txt
tomorrow. I figured out why I couldn't make it work on my machine
while getting Klimentkip going tonight (currently printing Vica
Illusion from RepG with Kilmentkip).
You are seeing serial problems that I'm not having. There's "Unknown:
[line noise]" in your log, corrupted resend requests, and you're
seeing tons of "start" indicating firmware resets. But the fact that
"ok" and "start" get through means you do have the right baud rate.
And I doubt you're controlling your board over dialup... What
platform are you on? Linux? I wonder if there's some other program
fighting to open your device, changing the parameters, causing RTS to
toggle leading to resets, etc. Perhaps RepG needs to do some kind of
locking it isn't doing?
> The last log got cut off, so i have a similar one posted herehttp://dl.dropbox.com/u/569387/seeduino%20teacup%20repg.txt
>
> the log shows repg and the arduino talking. I didn't hit anything
> except to select the appropriate serial port, then restart repg and
> start logging
>
> here is a new log from yesterdays version. A lot of red in that one,
> but it still shows as connected.
>
> http://dl.dropbox.com/u/569387/seeduino%20teacup%20repg%20new%20build...
> the log shows repg and the arduino talking. I didn't hit anything
> except to select the appropriate serial port, then restart repg and
> start logging
>
> here is a new log from yesterdays version. A lot of red in that one,
> but it still shows as connected.
>
>
> i tried it out on a rbbb arduino and a duemilanove 328. I couldn't get
> it to connect to the rbbb with or without auto-reset, and I don't want
> to cut the trace in order to disable auto reset on the 328 right now.
> If i can find my stock diecimillia I will try it on that as well.
>
> Thanks for your hard work.
>
> On Apr 6, 1:37 am, Ben Jackson <b...@ben.com> wrote:
>
>
>
>
>
>
>
> > The auto-reset can lead to timeouts the first time it tries to connect
> > because it's waiting for the bootloader to time out and call the real
> > app. Usually hitting "connect" fixes it, but I may need to increase
> > the timeout.
>
> > I see now that Teacup initializes with "start" + "ok". That extra
> > "ok" is like saying "ok, I already got that first command, that you
> > haven't even sent yet..." I didn't run into that when I tried Teacup
> > earlier tonight because I connected well after the reset.
>
> > Can I assume each of those '<< start' lines is you hitting reset? If
> > so I think you will be able to connect by resetting the board with
> > RepG disconnected and then hit 'connect' after. I was actually
> > driving Teacup with RepG earlier (also updated the binaries and pushed
> > a fix to make the all-relative extruder control work).
>
> > I will work on a way to eat that first "ok" after start. If you see
> > updated binaries athttp://ben.com/reprap(newerthan this message ;-)
> i tried it out on a rbbb arduino and a duemilanove 328. I couldn't get
> it to connect to the rbbb with or without auto-reset, and I don't want
> to cut the trace in order to disable auto reset on the 328 right now.
> If i can find my stock diecimillia I will try it on that as well.
>
> Thanks for your hard work.
>
> On Apr 6, 1:37 am, Ben Jackson <b...@ben.com> wrote:
>
>
>
>
>
>
>
> > The auto-reset can lead to timeouts the first time it tries to connect
> > because it's waiting for the bootloader to time out and call the real
> > app. Usually hitting "connect" fixes it, but I may need to increase
> > the timeout.
>
> > I see now that Teacup initializes with "start" + "ok". That extra
> > "ok" is like saying "ok, I already got that first command, that you
> > haven't even sent yet..." I didn't run into that when I tried Teacup
> > earlier tonight because I connected well after the reset.
>
> > Can I assume each of those '<< start' lines is you hitting reset? If
> > so I think you will be able to connect by resetting the board with
> > RepG disconnected and then hit 'connect' after. I was actually
> > driving Teacup with RepG earlier (also updated the binaries and pushed
> > a fix to make the all-relative extruder control work).
>
> > I will work on a way to eat that first "ok" after start. If you see
Triffid Hunter
Apr 7, 2011, 10:08:50 PM4/7/11
to make...@googlegroups.com
Teacup has examples of soft-disabling auto reset in func.sh with stty -hupcl and friends, I use it all the time to selectively reset on port open. All those starts in your logs suggest that you have something resetting your arduino a lot, perhaps noisy power?
On 07/04/2011 2:39 PM, "tinyenormous" <ross...@gmail.com> wrote:
Hi ben!
The last log got cut off, so i have a similar one posted here
http://dl.dropbox.com/u/569387/seeduino%20teacup%20repg.txt
the log shows repg and the arduino talking. I didn't hit anything
except to select the appropriate serial port, then restart repg and
start logging
here is a new log from yesterdays version. A lot of red in that one,
but it still shows as connected.
http://dl.dropbox.com/u/569387/seeduino%20teacup%20repg%20new%20build.txt
i tried it out on a rbbb arduino and a duemilanove 328. I couldn't get
it to connect to the rbbb with or without auto-reset, and I don't want
to cut the trace in order to disable auto reset on the 328 right now.
If i can find my stock diecimillia I will try it on that as well.
Thanks for your hard work.
On Apr 6, 1:37 am, Ben Jackson <b...@ben.com> wrote:
> The auto-reset can lead to timeouts the f...
> updated binaries athttp://ben.com/reprap(newer than this message ;-)
> then try them out.
>
> Thanks for the log.
>
> On Apr 5, 9:58 pm, tinyenormous <rossd...@gmail.com...
tinyenormous
Apr 8, 2011, 8:44:03 PM4/8/11
to MakerGear - Make Today, Change Tomorrow
Thanks for the thoughts. I don't know what could be causing it. The
arduino has been connected and powered via usb, with my laptop plugged
in to wall power. I'm running a macbook pro. As i mentioned before,
this is absolutely the barest setup imagineable. Literally nothing is
plugged into the arduino, so I can't be overloading the power supply
Also, I don't want anyone to feel like they have to solve my weird
connectivity problems. I'm just putting them in as a data point.
I've got a bunch of arduinos. You keep putting out versions, I'll keep
testing 'em!
On Apr 7, 8:08 pm, Triffid Hunter <triffid.hun...@gmail.com> wrote:
> Teacup has examples of soft-disabling auto reset in func.sh with stty -hupcl
> and friends, I use it all the time to selectively reset on port open. All
> those starts in your logs suggest that you have something resetting your
> arduino a lot, perhaps noisy power?
>
> The last log got cut off, so i have a similar one posted herehttp://dl.dropbox.com/u/569387/seeduino%20teacup%20repg.txt
arduino has been connected and powered via usb, with my laptop plugged
in to wall power. I'm running a macbook pro. As i mentioned before,
this is absolutely the barest setup imagineable. Literally nothing is
plugged into the arduino, so I can't be overloading the power supply
Also, I don't want anyone to feel like they have to solve my weird
connectivity problems. I'm just putting them in as a data point.
I've got a bunch of arduinos. You keep putting out versions, I'll keep
testing 'em!
On Apr 7, 8:08 pm, Triffid Hunter <triffid.hun...@gmail.com> wrote:
> Teacup has examples of soft-disabling auto reset in func.sh with stty -hupcl
> and friends, I use it all the time to selectively reset on port open. All
> those starts in your logs suggest that you have something resetting your
> arduino a lot, perhaps noisy power?
>
>
> the log shows repg and the arduino talking. I didn't hit anything
> except to select the appropriate serial port, then restart repg and
> start logging
>
> here is a new log from yesterdays version. A lot of red in that one,
> but it still shows as connected.
>
> http://dl.dropbox.com/u/569387/seeduino%20teacup%20repg%20new%20build...
> the log shows repg and the arduino talking. I didn't hit anything
> except to select the appropriate serial port, then restart repg and
> start logging
>
> here is a new log from yesterdays version. A lot of red in that one,
> but it still shows as connected.
>
>
> i tried it out on a rbbb arduino and a duemilanove 328. I couldn't get
> it to connect to the rbbb with or without auto-reset, and I don't want
> to cut the trace in order to disable auto reset on the 328 right now.
> If i can find my stock diecimillia I will try it on that as well.
>
> Thanks for your hard work.
>
> On Apr 6, 1:37 am, Ben Jackson <b...@ben.com> wrote:
>
>
>
>
>
>
>
> > The auto-reset can lead to timeouts the f...
> > updated binaries athttp://ben.com/reprap(newerthan this message ;-)
> i tried it out on a rbbb arduino and a duemilanove 328. I couldn't get
> it to connect to the rbbb with or without auto-reset, and I don't want
> to cut the trace in order to disable auto reset on the 328 right now.
> If i can find my stock diecimillia I will try it on that as well.
>
> Thanks for your hard work.
>
> On Apr 6, 1:37 am, Ben Jackson <b...@ben.com> wrote:
>
>
>
>
>
>
>
> > The auto-reset can lead to timeouts the f...
Ben Jackson
Apr 9, 2011, 5:09:05 AM4/9/11
to MakerGear - Make Today, Change Tomorrow
Ah, the Macbook may be related. I don't have a Mac at home to test
on. My money is still on some other process (could be almost
anything, like a PDA sync app searching for a connected PDA) opening
your serial port and changing the settings. What name does the serial
port get in the menu where you select a port?
I did upload new binaries (and pushed new diffs) to fix the start+ok
issue you saw with Teacup. This should eliminate the "Received OK
with nothing queued!" messages you saw after the firmware resets. I
would not expect it to allow you to print given the other events in
your log.
If I remember I will bring a board to work and try it on an iMac next
week.
> > > updated binaries athttp://ben.com/reprap(newerthanthis message ;-)
on. My money is still on some other process (could be almost
anything, like a PDA sync app searching for a connected PDA) opening
your serial port and changing the settings. What name does the serial
port get in the menu where you select a port?
I did upload new binaries (and pushed new diffs) to fix the start+ok
issue you saw with Teacup. This should eliminate the "Received OK
with nothing queued!" messages you saw after the firmware resets. I
would not expect it to allow you to print given the other events in
your log.
If I remember I will bring a board to work and try it on an iMac next
week.
Ben Jackson
Apr 16, 2011, 1:43:38 AM4/16/11
to MakerGear - Make Today, Change Tomorrow
I tracked down the problems resulting from reset-on-open (a behavior
my board does not exhibit for whatever reason, though it does reset on
RTS). I had to test by hitting reset just before connecting to get
the same effect.
There were two major issues: A function taking a timeout argument
actually slept for another (shorter) amount of time, so we didn't wait
very long for the firmware to wake up. The other was that if we sent
commands that got swallowed by the bootloader and then saw "start" we
didn't re-send the commands. Both are fixed.
Pushed to github, and binaries at: http://ben.com/reprap/
> > > updated binaries athttp://ben.com/reprap(newerthanthis message ;-)
my board does not exhibit for whatever reason, though it does reset on
RTS). I had to test by hitting reset just before connecting to get
the same effect.
There were two major issues: A function taking a timeout argument
actually slept for another (shorter) amount of time, so we didn't wait
very long for the firmware to wake up. The other was that if we sent
commands that got swallowed by the bootloader and then saw "start" we
didn't re-send the commands. Both are fixed.
Pushed to github, and binaries at: http://ben.com/reprap/
tinyenormous
Apr 25, 2011, 12:13:53 AM4/25/11
to MakerGear - Make Today, Change Tomorrow
Hey Ben! I got it to connect, thank you!
I'm currently using a mega 1280. I had to define the baud rate on the
arduino sketch, and then go in and change it in reprap.xml as well. I
set it to 19200, but that may well be part of the next issue. I was
able to connect and read the temp (with was really just adc noise as i
had nothing plugged in) but then trying to jog anything made it all
freeze up.
You were also correct about something else taking control of the
serial connection. After uploading the firmware to the chip it
wouldn't connect, but then after quitting the arduino environment it
would!
> > > > updated binaries athttp://ben.com/reprap(newerthanthismessage ;-)
I'm currently using a mega 1280. I had to define the baud rate on the
arduino sketch, and then go in and change it in reprap.xml as well. I
set it to 19200, but that may well be part of the next issue. I was
able to connect and read the temp (with was really just adc noise as i
had nothing plugged in) but then trying to jog anything made it all
freeze up.
You were also correct about something else taking control of the
serial connection. After uploading the firmware to the chip it
wouldn't connect, but then after quitting the arduino environment it
would!
Reply all
Reply to author
Forward
0 new messages