Sailfish 7.4 / 4.4 beta binaries

[Dan Newman]

We've put new 7.4 / 4.4 beta firmware up at the beta site,

http://jettyfirmware.yolasite.com/resources/beta/firmware.xml

FIRST BE WARNED that there are distinct binaries for the Rep 2X vs the Rep 2.
Also there's now a mysterious Rep 1 binary for Rep 1's with an ATmega 2560.

Significant changes:

0. The binaries for the ATmega 2560 bots are starting to make use of that
extra space. (No new features specific to them, but that's going to be
inevitable.)

1. No built in nozzle calibration script for dual extrusion printers. Instead, run the
script from RepG 40r13 - Sailfish if you need to calibrate your nozzles. (Files >
Scripts > Calibration). Once you've printed the test pattern, you can then select
Utilities > Nozzle Calibration and enter the numbers for X and Y. We'll post more
info on this at a later date. We also need to add interactive text messages to the
script to explain the procedure.

2. Heat During Pause now defaults to OFF. You won't see that unless you reset EEPROM
to factory defaults. This will largely benefit new users.

3. Pause heater timeout. If you pause the bot with the heaters enabled, then after
30 minutes idle, the pause will switch to a "cold" pause with the heaters turned off,
the LEDs turned off, and the extruder stepper motors disabled. This is only applicable
to Replicators (1, 2, 2X). Thing-o-Matics and Cupcakes use a different safety mechanism.

4. SDHC support. For all bots BUT Cupcakes, High Capacity SD cards (SDHC) are now
supported in addition to Standard Capacity (SDSC). We do not believe that SDXC (Extended
Capacity) cards work: we've not tried but will. We don't expect them to work. There's
simply no room in the 64K program space of a Cupcake to fit this in.

5. FAT-32 support. For all bots BUT Cupcakes, the FAT-32 file system is now supported.
Again, there's not enough space on Cupcakes for this. Besides, it doesn't buy you
anything without SDHC support as well.

6. P-Stop support. Tested and working on Thing-o-Matics and Replicator 1's. For
Rep 2's, someone will need to figure out the wiring for the unpopulated header on their
MightyBoard RevG and then solder in the necessary wiring if they want to test this. For
Cupcakes, we're open to suggestions: using an unused enstop won't work for Cupcakes which
have tied the min and max endstops together.

The P-Stop support uses

Thing-o-Matic: X-MAX endstop
Replicators: X-MIN endstop

When the endstop signal is pulled LOW, the firmware finishes the queued segments and
then enters a "cold" pause. While the pause is being entered, there's indication of
why. But once paused, you aren't told why you are paused. Make your Pause hardware
indicate that it fired, okay? We may add some text to the monitoring screen to indicate
a P-stop triggered pause state, but that can be a later day.

By default, P-Stop support is disabled. It can be enabled via RepG's Machine > Onboard
Preferences using the same tab as the Z-hold option. Or it can be enabled via the LCD
display (Utilities > General Settings on a Replicator; General Settings on a Thing-o-Matic).

Dan

[Gerald Orban]

Hi Dan,

Thanks for the update. For the 2560 builds are these for the brave few people who've desoldered the Atmega 1280 from the mightyboard and replaced it with a 2560 or is it for some other application?

[Ward Elder]

Dan, what model of ATMega 2560 will fit on the Rep 1?

Thank you,


Ward M. Elder
ElderSoft
42 Appleton St.
Winnipeg, MB
R2G1K5
(204) 791-7754 (Cell)

wa...@eldersoft.ca

--
You received this message because you are subscribed to the Google
Groups "Jetty Firmware" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jetty-firmwar...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Jetguy]

For brave souls just crazy enough to do that mod:)

> > Dan- Hide quoted text -
>
> - Show quoted text -

[Dan Newman]

On 4 Apr 2013 , at 2:02 PM, Gerald Orban wrote:

> Hi Dan,
>
> Thanks for the update. For the 2560 builds are these for the brave few
> people who've desoldered the Atmega 1280 from the mightyboard and replaced
> it with a 2560 or is it for some other application?

The former. However, there's at least one person making and selling
Rep 1 motherboards over in Europe. It's my understanding through
third parties that they have been in contact with MBI so as to make
sure that MBI will not take issue with their undertaking. Further,
they may consider using an ATmega 2560 rather than an ATmega 1280.

I myself do not have a Rep 1 board with an ATmega 2560 but two
different sets of capable EE's have offered to fixup my board with
one. I plan on taking up one of the offers.

Dan

[Dan Newman]

On 4 Apr 2013 , at 2:19 PM, Ward Elder wrote:

> Dan, what model of ATMega 2560 will fit on the Rep 1?

How big of a hammer do you have? It's a TQFP package,
thank goodness. (I.e., not a CBGA which is best left
to robots.)

Dan

[Ward Elder]

I have a SMT rework station so putting it in is not an issue (not BGA
stuff... that is nuts!). The DigiKey site shows several chips. I
assume it is a 16Mhz model or is it the 8Mhz?

Thank you,


Ward M. Elder
ElderSoft
42 Appleton St.
Winnipeg, MB
R2G1K5
(204) 791-7754 (Cell)

wa...@eldersoft.ca


-----Original Message-----
From: jetty-f...@googlegroups.com
[mailto:jetty-f...@googlegroups.com] On Behalf Of Dan Newman

[Dan Newman]

On 4 Apr 2013 , at 2:41 PM, Ward Elder wrote:

> I have a SMT rework station so putting it in is not an issue (not BGA
> stuff... that is nuts!). The DigiKey site shows several chips. I
> assume it is a 16Mhz model or is it the 8Mhz?

16 MHz.

Now for a WARNING. In the past (e.g., Thing-o-Matic), MBI provided a
special version of the otherwise standard Arduino bootloader. MBI's
version was customized to turn off FETs during that ~2 second wait period
while the bootloader waits for a possible firmware download but before
it turns control over to the bot's firmware.

I do not know if MBI did that with the bootloader for the Replicators.
They do have two copies of the compiled 1280 bootloader in their MightyBoard repository.
And they are different.

https://github.com/makerbot/MightyBoardFirmware/tree/master/bootloader/1280_bootloader

and

https://github.com/makerbot/MightyBoardFirmware/tree/master/dist/MightyBoard

I believe that the second one is the one they put onto their bots.

BUT, there's no sources for either in their repo (that I've spotted). And,
moreover, I just realized that if they were turning FETs and other outputs
off in the bootloader, then they would need different bootloaders for the
Rep 1 vs. Rep 2 (since they have the FETs and other critical outputs on different
ports). So, it may well be that MBI is no longer doing that: turning FETs
off while in the bootloader.

Dan

[Ward Elder]

This is getting sticky... maybe I will wait for someone else to take the
plunge!

Thank you,


Ward M. Elder
ElderSoft
42 Appleton St.
Winnipeg, MB
R2G1K5
(204) 791-7754 (Cell)

wa...@eldersoft.ca


-----Original Message-----
From: jetty-f...@googlegroups.com
[mailto:jetty-f...@googlegroups.com] On Behalf Of Dan Newman
Sent: April-04-13 4:53 PM
To: jetty-f...@googlegroups.com
Subject: Re: [Jetty Firmware] Sailfish 7.4 / 4.4 beta binaries

[Dan Newman]

On 4 Apr 2013 , at 2:52 PM, Dan Newman wrote:

>
> On 4 Apr 2013 , at 2:41 PM, Ward Elder wrote:
>
>> I have a SMT rework station so putting it in is not an issue (not BGA
>> stuff... that is nuts!). The DigiKey site shows several chips. I
>> assume it is a 16Mhz model or is it the 8Mhz?
>
> 16 MHz.
>
> Now for a WARNING. In the past (e.g., Thing-o-Matic), MBI provided a
> special version of the otherwise standard Arduino bootloader. MBI's
> version was customized to turn off FETs during that ~2 second wait period
> while the bootloader waits for a possible firmware download but before
> it turns control over to the bot's firmware.

E.g.,

Added modified bootloader for ECv2.2 boards. This bootloader reduces the startup
time and pulls the mosfet pins low immediately to prevent floating pins from
potentially overheating the mosfet on reset or startup.

With the MightyBoard, the Extruder Control function got folded into the motherboard.
So, presumably this functionality either got fixed at the hardware level or addressed
in the bootloader. (Or maybe it fell through the cracks? Anyone care to see if
the extruder power FETs are floating in the couple of seconds after power comes
on?)

[Jetguy]

Let me test quick and get back.

I got my testing mightyboard beside me, a programmer, and said
bootload respositories.

How in depth do I need to go here? I don't have a DSO, only a usb
scope http://www.pdamusician.com/dpscope/buy_it.html

In other words, what are we defining as a pass/ fail?

If the FET LEDs light at all, or going down to the scope level and
watching the output from turn on for a blip?

[Gary Crowell]

That would be ATMEGA2560-16AU   Digi-Key ATMEGA2560-16AU-ND

Gary

Dan

--
You received this message because you are subscribed to the Google Groups "Jetty Firmware" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jetty-firmwar...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
----------------------------------------------
Gary A. Crowell Sr., P.E., CID+

Linkedin  Elance  KE7FIZ

[Ward Elder]

Thank you for the chip number.  Very helpful.

 

Thank you,

 

 

Ward M. Elder

ElderSoft

42 Appleton St.

Winnipeg, MB

R2G1K5

(204) 791-7754   (Cell)

 

wa...@eldersoft.ca

 

From: jetty-f...@googlegroups.com [mailto:jetty-f...@googlegroups.com] On Behalf Of Gary Crowell

Sent: April-04-13 6:06 PM
To: jetty-f...@googlegroups.com

[Jamesarm97]

I have one on a board but haven't had much time to mess with it. Arduino code and serial port tests work but the last build (first 2560 build) didn't seem to work or, most likely something else was going on. Hopefully i will get more time to spend on it soon.

[Z LeHericy]

Question: Can the endstop used for P-Stop be configurable?

I use the X-max endstop on my bot with Gen4 (TOM) electronics for homing :-/

-Zeno LeHericy

//((=:Z:=))\\
INVENTIONS
Technologies
zinventions.com

On Thu, Apr 4, 2013 at 4:42 PM, Jamesarm97 <armstro...@gmail.com> wrote:

I have one on a board but haven't had much time to mess with it. Arduino code and serial port tests work but the last build (first 2560 build) didn't seem to work or, most likely something else was going on. Hopefully i will get more time to spend on it soon.

[shanen haan]

can the E-stop on the cupcake's 3G5D board be used? or is that tied into the endstops?

[shanen haan]

cupcake, like mine is still a cupcake lol. i mean the gen3 with the 3G5D board

[Jetguy]

Dan is reluctant and rightfully so to turn the E-Stop, whihc should
always be a true emergency stop, into a pause function.
So, while yes you think you have both min and max for X, Y, and Z,
they technically are using the same pin for min and max. You need them
to home so they cannot be reconfigured.

Dan has stated that right now, there is not way for a P-stop on gen3.

I know that's disapointing but gen3 is the minimum configuration and
cheapest thing to run Sailfish. P-stop is all about the filament jam
detection and that's not even finalized on my end yet. I have a
prototype and it's ugly.. It works but less than optimal. I'm
concerned with cost, reliability, and introducing new issues.

P-stop is not a normal pause function. I tis a trigggered pause with a
specific purpose.

With gen 3, you still have the big basics.
You can print from SD card but it means the bot is always controlled
from rep-g. You can disconnect once the print starts. You can pause
from rep-g just like all the other versions. You still get all the
acceleration and cool performance.

[Dan Newman]

On 4 Apr 2013 , at 3:28 PM, Jetguy wrote:

> Let me test quick and get back.
>
> I got my testing mightyboard beside me, a programmer, and said
> bootload respositories.
>
> How in depth do I need to go here? I don't have a DSO, only a usb
> scope http://www.pdamusician.com/dpscope/buy_it.html
>
> In other words, what are we defining as a pass/ fail?
>
> If the FET LEDs light at all, or going down to the scope level and
> watching the output from turn on for a blip?

Well, it's not really a pass/fail situation. I'm just trying to see if
the bootloader (assuming it's MBI's bootloader) asserts a LOW signal
to the output FETs gates. Supposedly the revE board uses PSMN7R0-30YL
MOSFETs. The gate is pin 4. Pins 1 - 3 are the source and the tab is
drain.

I'd just connect to the gate and ground and see if, when powered up,
you have a clean 0V signal being sent to the gate during those first
two seconds. You can look at the EXTRA FET and see what happens.

If the MBI bootloader isn't asserting LOW, then it may not be necessary
anymore (unlike with the old extruder controller). We can always ask
MBI if they concur -- that it is no longer needed. That makes our lives
easier as regards a bootloader for the 2560: just use the standard
Arduino one. Or, we can go ahead and assert LOW signals for all the
MOSFETs if we want.

Dan

[Dan Newman]

On 4 Apr 2013 , at 6:43 PM, Z LeHericy wrote:

> Question: Can the endstop used for P-Stop be configurable?

Not presently. And were we to do it, it would require a 2560 at present.
(Code space is again pretty tight and I don't have time to undo more C++
code bloat.) And, I'll have to see if any of the other endstops are on
the same interrupt vector: that would mean far less code by having only
one interrupt vector + routine and maybe just a bit mask if its on the
same port. (I may be asking for planetary alignment here.)

Dan

[Dan Newman]

On 4 Apr 2013 , at 7:48 PM, shanen haan wrote:

>
>>
>> can the E-stop on the cupcake's 3G5D board be used? or is that tied into
>>> the endstops?

That thought crossed my mind as well -- after all, you consider all the options,
right? However, that's the E-Stop and has a very well defined meaning: stop
everything absolutely AS SOON AS POSSIBLE because it's an emergency. It
is accepted that the work at hand may be destroyed. Tooling may even be
destroyed. However, it is an emergency. So, we should not provide firmware
or hardware which allows an E-Stop to be configured to behave in any other
way than as an E-Stop.

Dan

[Bluemetal]

Dan, 

if the bootloader in the 2560 MBI delivered boards is different than the original one from Arduino and theoretically the firmware update does not change the bootloader on the board, could I conclude that this could be an additional cause for the very different behavior in the communication between RepG and a 1280 and 2560 boards?

On a separate discussion with Jetguy we concluded that there is something weird with the communication with those boards, but I had not considered the firmware differences. I ultimately had to find a 1280 Mega to power my Ultimate TOM upgrade (jetguys A-machine frame) so it would talk to RepG.

[Jetguy]

No, on gen4 MBI did not mess with the bootloaders.

That issue you and I had was purely a timing issue and it stems from
not following the directions to cut the reset trace. Oddly, a 1280
with the FTDI chip can handle the reset in time and communicate to rep-
g, a 2560 takes longer and misses the timing point. they have
different USB to serial systems, and has nothing to do with the
bootloader.

The reason we are talking bootloaders here, I have a sneaky suspicion
that mightyboard blowups are related. It's both hardware design issue
and maybe this low level code contributes. I'm not saying this is the
cause! It's just another rock we have kicked over and found some
snakes. We don't know if they are the cause of death, but certainly
worth looking at and seeing if we can resolve it. If nothing else it
means just attempting to kick over all stones, big and small in the
system.

[Cymon]

Am I reading this right? Is SD card support on the Rep1? I've been hesitant to upgrade since the move to RepG's stupid SXG or whatever format (Why wouldn't you want acceleration on ALL THE TIME?) but this might convince me to brave the learning curve.

[Dan Newman]

On 5 Apr 2013 , at 9:39 AM, Bluemetal wrote:

> Dan,
>
> if the bootloader in the 2560 MBI delivered boards

Extruder Controller boards for the Thing-o-Matic.

> firmware update does not
> change the bootloader on the board,

Correct, a firmware update does not change the bootloader.

> could I conclude that this could be an
> additional cause for the very different behavior in the communication
> between RepG and a 1280 and 2560 boards?

No. The likely cause is using an Arduino board on which the RESET trace
has not been cut. However, MBI did make changes at some point in RepG's
comms but that was maybe two years ago? I do recall folks in the past
talking about changes in that area, but I wasn't following those discussions
back then.

>
> On a separate discussion with Jetguy we concluded that there is something
> weird with the communication with those boards, but I had not considered
> the firmware differences.

There is no firmware difference beyond a compile switch passed to avr-gcc
and a check done by avr-dude when loading the firmware to the AVR. If
you go through the sources you will see that the code conditionalized on
a 1280 always is identical to that for a 2560. That is, the conditionals
are always

#if defined(__AVR_ATmega_1280__) || defined(__AVR_ATmega_2560__)

So, the firmware itself makes no distinction between a 1280 and a 2560.
Thus, the only differences are in the USB hardware on the Arduino card
itself.

> I ultimately had to find a 1280 Mega to power my
> Ultimate TOM upgrade (jetguys A-machine frame) so it would talk to RepG.

Lots of people, Jetty and myself included, use ATmega 2560's with their
ToMs.

Dan

[Jamesarm97]

Dan, in regards to the mysterious 2560 Rep1 board, is there anything you can think of that will do a reset / WDT if only the processor is on the board? We were repairing in steps and have the firmware on the 2460 and the LCD shows the r00999 v7.4 and beeps then after 3 seconds it resets. I don't know if it is a safety or some other issue we need to look at. I am trying to get it up and running in steps before putting all the parts back on.

Thanks

[Jamesarm97]

Found it. Safety override was doing it. Have a 2560 running on the mighty board. Testing will continue...

[Dan Newman]

On 5 Apr 2013 , at 1:07 PM, Cymon wrote:

> Am I reading this right? Is SD card support on the Rep1? I've been hesitant
> to upgrade since the move to RepG's stupid SXG or whatever format (Why
> wouldn't you want acceleration on ALL THE TIME?) but this might convince me
> to brave the learning curve.

SDHC + FAT-32 is on the Rep 1, yes. But my advice to folks doing commercial
work is to wait until the beta is over and the release is out.

Dan

[Dan Newman]

The WDT is set to ~8 seconds. My guess is that some sort of missing hardware
is causing something done by the AVR to trigger an error and reset. The 3
seconds is the result that very early on, a splash screen is thrown up,
then there's a 3 second pause (Motherboard.cc/reset()), and then more
initialization is carried out. It's not clear to me what part of the
initialization might then trigger an error, but my guess is that's what's
happening.

RGB is initialized (RGB_LED.cc/init()) which initializes the I2C interface
and then attempts comms on it

Temp sensors are initialized

Then i/o is attempted to process incoming commands

Dan

[Dan Newman]

On 5 Apr 2013 , at 1:56 PM, Jamesarm97 wrote:

> Found it. Safety override was doing it. Have a 2560 running on the mighty

> board. Testing will continue…

Sweet. By the way, while waiting at the doctor's I double checked all processor-type
conditionalized code. We're good to go: anything that was conditionalized on a 1280 also
included the 2560. I was pretty sure that I had checked that last year, but doesn't hurt
to check again as I did.

Dan

[Jetguy]

A note of caution with these Betas in my informal testing tonight, the
safety is so good, it might frustrate you.
If you have a flakey HBP sensor or a bad thermocouple, you will be
notified on the first boot!! That's good, but, if you make mistake or
say previously you had set 2 extruders and only have a working
thermocouple on one, you cannot get back in the firmware to change it.
If you are in a warning message error mode, you cannot connect via USB
to see or change onboard preferences.

Note, this was a Replicator1 an we saw this with both the 1280 and
special 2560 versions.

The good news, is, if you get stuck, just go back to the non-beta. If
you have good hardware, you might not ever see this but if you make a
mistake and set 2 extruders and don't have a spare TC on hand, you are
in for some fun.