Null Version - I have an idea

[toomanyplugs]

I too am getting Null version reported after upgrading the firmwares,
but I've been playing with it today and I noticed a few things (sorry
it's so long, I didn't know the best way to gather all my notes):

- I had a stable config with RepG 0012, motherboard v1.6, extruder
v1.8 (with Makergear's fix for external stepper extruder).

- today I upgraded the software all around: RepG 0021, motherboard
v2.4 (compiled from git today 11/26), Extruder v2.6 (compiled from
git, with external stepper support)

- RepG starts to give Null versions on the Extruder, but the
motherboard connects fine. Red debug LED on mb blinks slowly, 2-3
times every second or so (2-3 on, 1 sec pause, 2-3 on, etc.).

- Opening the control panel, I see occasional blips on the temperature
graph that indicate that the Extruder is occasionally connecting
(blips from 0 degC to ~room temp, then back to 0 degC).

- I can control the extruder stepper by the control panel fine.
Changing the temperature causes the Channel B LED to light briefly
then go out. If I let it sit, it'll continue to occasionally come on/
off, with occasional blips on the graph. THIS seems to indicate a
noise issue on the line between the mb and the extruder.

- Here's the kicker: when I downgrade the motherboard software ONLY to
v1.6, it connects to the extruder fine (but RepG keeps warning me I
should go to v2.x on the motherboard). Everything works fine,
temperature graph is consistent, extruder motor spins as expected.

- I tried all combinations of firmware available in RepG: mb v1.6 with
ec v2.x, mb v2.x with extruder 2.x. It seems that only mb v1.6 is
stable with extruder v2.x (of course, v1.6 and ec v1.8 is ok, too).

- So it seems like something changed in the communication protocol
between v1.6 and v2.x that makes it less robust and more prone to
noise. Anyone know what that could be?

For reference, I'm using a RepRap Mendel with the Mendel changes for
the Motherboard and Extruder (which means I don't have the standard
PSU, but I connect the 12V directly to the Extruder). I also don't
have a shielded CAT5 line from the motherboard to the Extruder, but
rather 2 wires of a ribbon cable.

It may also be pertinent that I *don't* have the 180 ohm resistor on
the motherboard that terminates the RS485, but I *do* have it on the
extruder.

So, can anyone weigh in on what changed in protocol between v1.6 and
v2.x?

[toomanyplugs]

A little more information:

I can successfully go back and forth between firmware versions and
recreate the problem, both motherboard and extruder. I know that RepG
is updating the firmware correctly because I can see the avrdude
progress bars in the terminal window (write and verify both complete
successfully). So I know it's not a hardware thing that changed. I
mean, my boards aren't broken.

Board hardware versions: Motherboard v1.2, Extruder Controller v2.2

[Koen Kooi]

I 'fixed' that by using a short cat6 cable on my mendel.

> --
> You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.
> To post to this group, send email to make...@googlegroups.com.
> To unsubscribe from this group, send email to makerbot+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/makerbot?hl=en.
>

[toomanyplugs]

Hmm. I installed a shielded 2-conductor wire yesterday, but it didn't
seem to do anything. The shield drain wire was connected to one of the
ground pins of the RS485 ports, on both the motherboard and the
extruder.

When I flashed the mb to 2.4, it still couldn't recognize the
Extruder. The blips in the temperature graph in the control panel
didn't seem to be more frequent, either (which I would have expected
if it was a noise/dropped packet issue that the shielding would have
fixed). I can still command the extruder motor back and forth, but
temperature control is sporadic and not trustworthy enough to try to
actually build something.

I was trying to dig around in the firmware source to see what could
have changed between v1.6 and v2.x in the communication, but I'm
flying blind. Does anyone else know more about what changed on a low
level that could shed some light? Could there be a packet retry or
timeout that got shorter, leading to more dropped packets?

On Nov 27, 1:17 am, Koen Kooi <k...@beagleboard.org> wrote:
> I 'fixed' that by using a short cat6 cable on my mendel.
>

[Blokkendoos]

Only to confirm that this is not an isolated incident.

After I upgraded my MakerBot it seemed to work though get stuck after
the first 5 or more layers, regardless what printed. Downgraded and
everything works as before, that is Ok.
Too lazy to investigate, already being happy with a working MB, I have
not found a solution for this.

Details of the working configuration:
MB batch 9 #436
Mobo/EC 1.6/1.8
ReplicatorG-0013

Regards,
Johan

> > v2.x?- Hide quoted text -
>
> - Show quoted text -

[Dore Mark]

Given your advice above, I'll downgrade my MB to 1.6 and test from
there.

I do recall in my instance that it was a slow spiral downward with
regard to the extruder communications. For some reason about a month
ago, I no longer got the"you're using an outdated firmware version"
notification in RepG for the extruder. Then, a few days ago, I not
longer got communications at all to it.

I'll post more notes as I find more - I'm also in contact with
Makerbot support.

-Dore

[toomanyplugs]

A bit more investigating:
(TL;DR: it's still not working with mb v2.x)

After reading around about the 180 ohm terminating resistor, I tried
adding one to my motherboard (that didn't have one per the advice of
the build instructions). So now I'm using 180ohm resistors on both the
mb and the ec, *and* a shielded cable with both ends of the drain wire
connected to ground, and I don't see any reduction in the number of
dropped packets.

To check the packets, I set the RepG logger to record "ALL" in the
preferences window (which is awesome, thanks guys!), and was able to
see the handshake going on between RepG and the motherboard. Here's
what I found (This is probably not useful to many people, but it may
be useful to the few people who can do something about it):

RepG 0021 / mb v1.6 / ec v2.6 : Bot connects fine. Logger window shows
RepG asking for mb version, name, ec version, name, etc. Motherboard
responds to all of this in both ASCII and with return packets.
Motherboard version queries from RepG get responded to with "Host
Timeout" in ASCII as well as a success response packet (D5.1.1.5e).
Extruder queries from RepG passed through the motherboard get a
response of "Slave CRC Mismatch" in ASCII as well as a success
response (D5.appropriate.response). The responses seem to be parsed by
RepG ok, regardless of what the mb is trying to say in ASCII. I
believe this is just an artifact of the old firmware, right? MB sends
an ASCII error but also copies the packet over in totality, and RepG
ignores everything that isn't preceded by D5 start byte. At least,
this is how it seems to work to me.

RepG 0021 / mb v2.4 (git 11/25) / ec v2.6 : Bot usually connects fine,
but occasionally says "Unable to connect to firmware" and requires a
couple tries. Logger shows that RepG is connecting to the mb fine
(version and firmware name queries get appropriate responses form mb),
but often the extruder queries drop either the Version query or the
Firmware name query. A loss of both results in "Unable to connect". A
loss of one (usually the version number) prompts RepG to say that the
Tool can't be found, null version, make sure it's on, etc.

Opening the control panel at this point gives the behavior I've
mentioned in previous posts, but now the logger shows the packets. In
response to temperature queries, the packets are one of three types:
either generic error (D5.0.0), downstream timeout (D5.1.7.83), or
success (D5.temperature response). The two error packets are the same
for when RepG tries to connect and it can't get the ec version or
firmware name. Enough retries and these errors go back and forth until
it gets lucky and catches the right response packet.

I can duplicate this by opening the serial line and talking to the mb
directly by passing RepG's packets to it and seeing the response. If I
spam the line enough with one of the extruder queries, eventually I
get the right response back a few times, but it's far from consistent.
(I'm using moserial in Ubuntu 9.10 since it can send/receive in hex).

Interesting to note that this bug seems to be the oldest still-open
issue in github (#37): https://github.com/makerbot/G3Firmware/issues#issue/37
I haven't tried the modifications to UART.cc suggested there, but
that's next.

(I'm sure this is all old news to the firmware crew, and I feel a bit
like an archaeologist foolishly digging through the artifacts left by
a people who are still around instead of just talking to them, but I'm
hoping that I'll hit upon something new and useful to someone and
they'll go, "Ohhhh, *that's* the problem" and then we can fix it.)

-Nik

[Rob Giseburt]

Just out of curiosity, would you be willing to try updating your bootloader on the EC?

To do that you need a programmer, like the UBSTinyISP (http://www.ladyada.net/make/usbtinyisp/) from Adafruit, or an Arduino would do (http://arduino.cc/en/Tutorial/ArduinoISP). 

If you download the firmware from github:https://github.com/makerbot/G3Firmware/tree/master

Then download the latest Arduino software http://arduino.cc

Make a folder called "hardware" (no quotes) inside the arduino sketches folder.

Copy/move the folder bootloader/hardware/arduino into that folder. 

Open/restart the Arduino program and Extruder Controller v2.2 should now show up in the Tools -> Board menu. Choose that, connect your programmer (ISP) to the EC, then choose Tools -> Burn Bootloader -> (The ISP you have.)

That will put the latest bootloader on your EC. 

Now, upload the EC Firmware from RepG again, and see if that fixes it. 

Also: do you have trouble uploading the firmware?

  -Rob

[toomanyplugs]

Rob,

I can reinstall the bootloader, I might try that tonight. I have the
USBTinyISP and Arduino 0018 (is the *latest* version really necessary?
I'm concerned about disrupting the stable Arduino environment I have
now).

Can you tell me what you're thinking? I'm a little worried about
changing bootloaders in case I bork it. Is there a good way to revert
if that didn't work?

-Nik

On Dec 1, 12:25 pm, Rob Giseburt <giseb...@gmail.com> wrote:
> Just out of curiosity, would you be willing to try updating your bootloader
> on the EC?
>
> To do that you need a programmer, like the UBSTinyISP (http://www.ladyada.net/make/usbtinyisp/) from Adafruit, or an Arduino would
> do (http://arduino.cc/en/Tutorial/ArduinoISP).
>
> If you download the firmware from github:https://github.com/makerbot/G3Firmware/tree/master
>

> Then download the latest Arduino softwarehttp://arduino.cc

[John Yang]

I think the latest arduino has optiboot boot loader as available option.

[Rob Giseburt]

The EC has a special bootloader that makes sure the MOSFETs are off
while loading new firmware.

Also, optiboot runs at a different speed, and wouldn't work with RepG
without modification.

-Rob

[Rob Giseburt]

I have a theory that one if the changes in the bootloader is being
propagated to after bootload time, and that change makes the TX/RX
work a little better. (I'm specifically thinking about a pullup on the
TX pin.)

This is probably not the case if you don't have trouble with uploading
firmware.

As an allternative solution, I can compile a test firmware that does
the change on it's own during init. I'll compile that later and upload
it. That way you don't have to worry about your bootloader if it's
already working ok.

-Rob

[toomanyplugs]

Rob,

I was able to successfully load the new bootloader using arduino-0021.
After that, I did a git pull and compiled the latest version of the
extruder firmware (which I see you've recently updated with the pullup
stuff in UART.cc).

Didn't seem to have an effect, unfortunately. The incidence of dropped
packets seems to be the same, including when I spam the serial line
directly from moserial.

On a hunch, I implemented your pullup idea in the motherboard firmware
as well (by setting D10 for RX on the Sanguino, *NOT* D0 like the ec).
Again, no effect :(

I'm still thinking there's something up with the implementation of the
RS485 on the software side, not the hardware. I mean, I've tried as
many of the basic and intermediate techniques to get the hardware
shielded and isolated as I could find around here, and I'm still
dropping packets (but only in v2.x!). I would think that the
communication protocol was way more robust than to be broken by some
very non-obvious hardware thing.

I'm certainly not bashing the awesome work that Adam and co. are doing
with the software! I'm just sad and disappointed that I can't use the
cool new features in v2.x and on.

[Rob Giseburt]

Very good snoop work. Very interesting results too.

I'm very curious what this could be. I'm not familiar enough with the
1.x code to know what changed. Perhaps someone else might have a clue?

I just switched to a Cat6e 5ft (!) cable from MB to EC (less than an
inch apart) and can get thru builds that were impossible before. I'm
still experimenting to see which part was the important change...

-Rob

[Rob Giseburt]

This is a unique opportunity to possibly get this fixed, guys. We have
a machine with the problem cleanly isolated, an a knowledgeable and
willing operator to work thru solving it...

Just saying.

-Rob

On Dec 2, 2010, at 1:13 AM, toomanyplugs <nnor...@gmail.com> wrote:

[Nikolai Norausky]

Indeed. :D

I'm not software-smart enough to solve it myself, but I can take
direction well and I try to take detailed notes!

[Adam Mayer]

Sorry I haven't been keeping up too well with the list-- I've been
slammed lately. The biggest barrier to fixing these issues has been
the lack of a machine to reproduce the problem with here.

I can offer some insight as to what changed in the comms between v1.X
and v2.X, and give you a possible fix to test.

There are two differences in the way 1.x and 2.x does comms. In the
1.x series, the transceivers were always in listen mode and the
software parsed and discarded the echoed bytes, whereas 2.x shuts down
the read line and the serial input while transmitting. The other
difference is the delay before responding; 1.x inserted a 50ms wait
time before the extruder response.

I am working on a version of the firmware that implements the 1.x
loopback style right now. I hope to have something for you to test
later today.

Thanks,
-a

On Dec 2, 10:36 am, Rob Giseburt <giseb...@gmail.com> wrote:
> This is a unique opportunity to possibly get this fixed, guys. We have
> a machine with the problem cleanly isolated, an a knowledgeable and
> willing operator to work thru solving it...
>
> Just saying.
>
>   -Rob
>

[Adam Mayer]

Okay, I've got some new firmware for y'all to try out.

I've built alternate versions of the latest 2.x firmware using the 1.x
comm loopback. You can try it out by opening ReplicatorG and changing
the firmware update URL to:
http://firmware.makerbot.com/alternate_comms/firmware.xml

Then quit and restart ReplicatorG. Install the new 2.6 firmware on
your extruder controller, and the 2.4 firmware on the motherboard.

If possible, I'd love for both people who are having issues and those
who aren't to give this a whirl; if it works for everything, we'll
move this into the mainstream for the next release. (Which is
currently slated for Friday. :P)

-a

[Nikolai Norausky]

Sweet! I'll give this a try this evening, thanks!

Quick question: what should I expect this new firmware to do with an
external stepper? Should I expect anything to happen there? I have a
dc motor I could hook up to the H-bridges if I need to.

-Nik

[Adam Mayer]

Hi Nik;

I've only done builds for the DC motor versions of the firmware at the
moment. If I get a chance later I'll put up the h-bridge stepper and
external stepper builds as well, or you can try to build them yourself
from git-- the code to test is in the "v1comms" branch of G3Firmware.

-a

On Dec 2, 3:28 pm, Nikolai Norausky <nnorau...@gmail.com> wrote:
> Sweet! I'll give this a try this evening, thanks!
>
> Quick question: what should I expect this new firmware to do with an
> external stepper? Should I expect anything to happen there? I have a
> dc motor I could hook up to the H-bridges if I need to.
>
> -Nik
>

[toomanyplugs]

\o/ SUCCESS!

It looks much better now. I ran a test print of an opened walled box
and it passed ok. No obvious packet loss (but with debug on in RepG,
everything flies by fast; maybe I'll try again with no debug and look
for Payload errors). Longer prints remain to be seen.

More info, for the record:
- To keep configurations consistent, I tried out the new firmware
using a DC motor for now. Both the mb and ec firmwares flashed no
problem.

- Mostly good packets. Occasional timeout packets (D5.1.7.83) with the
control panel (cpl) open, with corresponding temperature graph drop
outs. Used to be mostly generic error packets (D5.0.0) with occasional
timeouts and seldom good packets.

- Motherboard consistently flashing red debug LED once a second. This
used to mean generic error, but did you turn this on as a "test"
firmware, Adam? In any case, the mb debug used to flash 3x, so that's
different.

- <brief panic about nothing but timeout packets until I realize ec
comms cable came loose!>

- Running the DC motor didn't seem to increase packet loss that I
could tell.

- What *did* seem to cause dropped packets, if at all, was sending a
command (set temperature, motor speed, fwd/rev, etc.) at just the
right time caused a drop of 1-3 packets and corresponding momentary
temperature graph drop. I think this is probably because command
packets override queries, right? This didn't happen all the time, but
only if I got the timing *just* right.

- Another interesting thing was that if I left the Pololu stepper
motor connected as before, and moved my hand close to the Quadrature
header, I could induce the stepper motor to turn. Quad 7/8 are the
step/dir pins for this config. D10 is enable, and I guess when it's
not configured for ext stepper D10 goes low (which enables the
driver). Moving D10 wire to D10's VCC turned off the stepper.

- It's curious though that hand noise was consistent enough to produce
*steady* stepper motion, not jerky as I would expect from random
noise. Perhaps my hand acted as an antenna for some nearby bit
hashing, like maybe the RS485 comms driver is really noisy? Hmm.

Anyway, thanks very much Adam for the new firmware!

Nik

[toomanyplugs]

weird, logging in from the groups page makes me "toomanyplugs", but
replying from email gives my full name. Anyway, I'm one and the same ;)

[Boris Camelo]

after change the new firmware, works better. But i have a problem, in some cases after some minutes, the extruder motor dc stop and not extrude abs.When dc motor is stoped the machine continue printinting the part. Can you help me?. I have two machines with this problem ? The problem is "loss package in rs485 " ?, the problem is "noise by DC motor"? and other question, stepper motor generate electric noise.

PLEASE I'M very worried 

BORIS CAMELO

2010/12/2 toomanyplugs <nnor...@gmail.com>

weird, logging in from the groups page makes me "toomanyplugs", but
replying from email gives my full name. Anyway, I'm one and the same ;)

[bgc...@gmail.com]

I burn new firmware , works better but i have a problem.. In some times the dc motor extruder stop but the machine continue move. Can you help me? I have 2 machines with the same problem.

Heeeeeelp please!

Boris camelo
Enviado desde mi Nokia
-----Mensaje original-----
De: Adam Mayer
Enviados: 02/12/2010 15:17:08
Asunto: [MakerBot] Re: Null Version - I have an idea

Okay, I've got some new firmware for y'all to try out.

I've built alternate versions of the latest 2.x firmware using the 1.x
comm loopback. You can try it out by opening ReplicatorG and changing
the firmware update URL to:
http://firmware.makerbot.com/alternate_comms/firmware.xml

Then quit and restart ReplicatorG. Install the new 2.6 firmware on
your extruder controller, and the 2.4 firmware on the motherboard.

If possible, I'd love for both people who are having issues and those
who aren't to give this a whirl; if it works for everything, we'll
move this into the mainstream for the next release. (Which is
currently slated for Friday. :P)

-a

--

[toomanyplugs]

Hi Boris,

What you've described sounds like it could kind of be one of a number
of things. Unfortunately, I don't have a lot of experience with the DC
motors, since I usually run a stepper extruder.

If you have already upgraded to the new firmware, I would suggest
maybe starting a separate thread for your motor issue so that it can
get noticed in the main group. Maybe someone there with more knowledge
can help?

Make sure to include as much detail as you can about your bot's
configuration, what the ReplicatorG terminal is saying, and LEDs that
are flashing or not, things you've already tried, etc.

Good luck!

Nik

On Dec 3, 11:33 am, Boris Camelo <bgc...@gmail.com> wrote:
> after change the new firmware, works better. But i have a problem, in some
> cases after some minutes, the extruder motor dc stop and not extrude
> abs.When dc motor is stoped the machine continue printinting the part. Can
> you help me?. I have two machines with this problem ? The problem is "loss
> package in rs485 " ?, the problem is "noise by DC motor"? and other
> question, stepper motor generate electric noise.
>

> *PLEASE I'M *very worried
>
> BORIS CAMELO
> **

[AshK]

Hi - I'm new to this, but am having the null version error. Was
working fine yesterday, now I'm toast.

[Bill Culverhouse]

Meant to post this sooner but forgot.

 

May work for others, I suspected a problem with my extruder controller

for a while. I had weird problems and had to upgrade/downgrade the extruder

earlier on. Since version 2.5 I've gotten the toolhead not found error on the

newer firmwares 2.5 2.6 and 2.7.

 

I thought that I might have a problem with the boot loader so I hooked

up to my tinyISP and burned the boot loader found at the repG google

code site and then reburned the firmware through regular repg methods

and now have no problems. Running MB v 2.4 EC v 2.7.

 

This may not fix everyone but is definitely something to try.

 

-b