Sailfish 7.4 / 4.4 beta binaries

405 views
Skip to first unread message

Dan Newman

unread,
Apr 4, 2013, 4:53:24 PM4/4/13
to jetty-f...@googlegroups.com
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

unread,
Apr 4, 2013, 5:02:49 PM4/4/13
to jetty-f...@googlegroups.com
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

unread,
Apr 4, 2013, 5:19:42 PM4/4/13
to jetty-f...@googlegroups.com
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

unread,
Apr 4, 2013, 5:21:54 PM4/4/13
to Jetty Firmware
For brave souls just crazy enough to do that mod:)
> > Dan- Hide quoted text -
>
> - Show quoted text -

Dan Newman

unread,
Apr 4, 2013, 5:28:52 PM4/4/13
to jetty-f...@googlegroups.com

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

unread,
Apr 4, 2013, 5:37:23 PM4/4/13
to jetty-f...@googlegroups.com

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

unread,
Apr 4, 2013, 5:41:09 PM4/4/13
to jetty-f...@googlegroups.com
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

unread,
Apr 4, 2013, 5:52:52 PM4/4/13
to jetty-f...@googlegroups.com

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

unread,
Apr 4, 2013, 5:55:11 PM4/4/13
to jetty-f...@googlegroups.com
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

unread,
Apr 4, 2013, 6:00:51 PM4/4/13
to jetty-f...@googlegroups.com

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

unread,
Apr 4, 2013, 6:28:02 PM4/4/13
to Jetty Firmware
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

unread,
Apr 4, 2013, 7:06:02 PM4/4/13
to jetty-f...@googlegroups.com
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+

Ward Elder

unread,
Apr 4, 2013, 7:09:37 PM4/4/13
to jetty-f...@googlegroups.com

 

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

unread,
Apr 4, 2013, 7:42:17 PM4/4/13
to jetty-f...@googlegroups.com
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

unread,
Apr 4, 2013, 9:43:03 PM4/4/13
to jetty-f...@googlegroups.com
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

unread,
Apr 4, 2013, 10:48:40 PM4/4/13
to jetty-f...@googlegroups.com
can the E-stop on the cupcake's 3G5D board be used? or is that tied into the endstops?

shanen haan

unread,
Apr 4, 2013, 10:49:45 PM4/4/13
to jetty-f...@googlegroups.com
cupcake, like mine is still a cupcake lol. i mean the gen3 with the 3G5D board

Jetguy

unread,
Apr 4, 2013, 11:14:47 PM4/4/13
to Jetty Firmware
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

unread,
Apr 4, 2013, 11:24:32 PM4/4/13
to jetty-f...@googlegroups.com

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

unread,
Apr 4, 2013, 11:35:11 PM4/4/13
to jetty-f...@googlegroups.com

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

unread,
Apr 4, 2013, 11:43:27 PM4/4/13
to jetty-f...@googlegroups.com

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

unread,
Apr 5, 2013, 12:39:26 PM4/5/13
to jetty-f...@googlegroups.com
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

unread,
Apr 5, 2013, 2:31:57 PM4/5/13
to Jetty Firmware
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

unread,
Apr 5, 2013, 4:07:31 PM4/5/13
to jetty-f...@googlegroups.com
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

unread,
Apr 5, 2013, 4:30:28 PM4/5/13
to jetty-f...@googlegroups.com

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

unread,
Apr 5, 2013, 4:34:40 PM4/5/13
to jetty-f...@googlegroups.com
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

unread,
Apr 5, 2013, 4:56:10 PM4/5/13
to jetty-f...@googlegroups.com
Found it. Safety override was doing it. Have a 2560 running on the mighty board. Testing will continue...

Dan Newman

unread,
Apr 5, 2013, 4:58:05 PM4/5/13
to jetty-f...@googlegroups.com

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

unread,
Apr 5, 2013, 5:10:53 PM4/5/13
to jetty-f...@googlegroups.com
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

unread,
Apr 5, 2013, 5:13:15 PM4/5/13
to jetty-f...@googlegroups.com

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

unread,
Apr 6, 2013, 3:32:49 AM4/6/13
to Jetty Firmware
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.

Dan Newman

unread,
Apr 6, 2013, 11:26:00 AM4/6/13
to jetty-f...@googlegroups.com

On 6 Apr 2013 , at 12:32 AM, Jetguy wrote:

> 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.

FWIW, and that's not much as I've not tried this yet myself, it looks
like this is a downstream effect of fixing a logic bug which was in both
the MBI and Sailfish firmware.

As folks are aware there's a logic bug in both the currently released MBI
and Sailfish firmwares that allows a disconnected heater sensor to be
ignored. It's slightly less of an issue on Sailfish as Sailfish doesn't
attempt to read disabled sensors. The MBI firmware does (owing to a
different logic bug we previously fixed in Sailfish but which is still
in the released MBI firmware). This ignoring disconnected sensors is
what has been allowing the bot to continue to print after the temp
sensor has failed. (And coupled with yet a different bug in the MBI
firmware was what was allowing a print to start even when the sensor
had failed: treating the error temp of 1024 as a real, measured temp.)
What a quagmire!

Anyway, having had fixed these assorted bugs in Sailfish and making
them publicly available for everyone working on the sources, a downstream
bug has appeared. Namely, it looks like the code for handling the warning
message is too agressive. Owing to the upstream errors, no one had
actually properly tested the warning handling in this case it seems.
Well, that's what field testing helps immensely with. The fix should
be pretty straightforward. And, of course, this is only an issue when
you either have a failed sensor OR you accidentally have the tool count
set too high or have the HBP installed flag set when you don't have
an HBP.

Dan

Dan Newman

unread,
Apr 6, 2013, 1:08:53 PM4/6/13
to jetty-f...@googlegroups.com
If you are running the Sailfish 7.4 beta, I urge you to upgrade to r1002.

For Replicators (1, 2, 2X) I've uploaded a new r1002 which is less aggressive about
the heater failure warning. I.e., you get the warning and you can dismiss it and life
goes on, just with the heater disabled is all. With the r1001 behavior, you couldn't
dismiss the message nor do much of anything else. You can, however, still upload firmware:
that's a separate uProcessor which, when it sees the firmware bits sliding down the
wires, it puts the main uProcessor into a special state, receptive to new instructions.

I put through my Rep 1 into said state to test. BTW, it's nice now having the
specific heater identified in the error messages. For those of us with Rep 1
HBP connectors on death row, it will at least tell us what specifically failed
without our having to do a process of elimination game. You Rep 2 owners with
only one heater don't need to worry that detail.

And, FWIW, I had actually made a change to the code which handles the warning
message. It was a bad change on my part: MBI had it right. So I made my own little
patch of mess in the quagmire of bugs that were in this part of the firmware.

Dan

Jamesarm97

unread,
Apr 6, 2013, 2:08:28 PM4/6/13
to jetty-f...@googlegroups.com
Thanks for the fast fix. It was fun working on a board repair and not being able to do anything until I dug up a few temperature sensors to plug in.

Dan Newman

unread,
Apr 6, 2013, 3:50:25 PM4/6/13
to jetty-f...@googlegroups.com

On 6 Apr 2013 , at 11:08 AM, Jamesarm97 wrote:

> Thanks for the fast fix. It was fun working on a board repair and not being
> able to do anything until I dug up a few temperature sensors to plug in.

Sorry about that. Of course, you can always plug in a 10K resistor for
the thermistor and something really low for the t/c's. A piece of
wire should work, but the RevE board is touchy so I cannot recommend
trying that.

Dan

Dan Newman

unread,
Apr 6, 2013, 11:13:35 PM4/6/13
to jetty-f...@googlegroups.com

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.

Joe,

Also wanted to fill you in on some features you may appreciate. Last release
and this one, we're focusing more on usability. You've had some good input
in that dept. Here's some things which should interest you

1. I recall you mentioning that you task other family members with printing
several copies of the same model. And their lives would be easier if they
didn't have to go back to the "Print from SD" menu and then re-select the
same model. Moreover, doing that introduces an error case -- they select
the wrong file.

So in the 7.3 release, we added a new screen which comes up at the end of
the print:

Elapsed time: hh:mm
Filament used: xxxxxx m
Print another
* Return to main menu

The last item, "Return to main menu" is what is selected so you just
have to press "M" to get back to the top menu. But, you can press UP
and then M and repeat the print. And you also get nice print stats
as well

2. SD card error checking. This is already helping out some users who
were having prints fail part way through. Bot would just seem to hang
mid print. However, the menus would behave as though the print was done.
That's because reading the SD card file failed -- terminated early.
SD card reads can be error checked and if an error is detected, the read
re-done. You need to enable this; it's off by default.

3. SD card folder support. Really nice. Keep a single SD card with
utilities/scripts/EEPROM dump in one folder, and then other folders with
other goodies.

4. Better error reporting and diagnostics. For example, no more telling
you your SD card isn't formatted FAT-16 when it is. The MBI firmware was
treating any error from a high level call as meaning the card wasn't formatted
FAT-16. We don't do that anymore: you get more correct error messages.
And, my guess, is that most often it will be problems with communication
errors.

5. More of 4 in this release. For instance, temp reading error reports tell you
WHICH temp sensor failed. On a Rep 2, that's ho-hum: it only has one temp sensor.
On a Rep 1, it probably means the HBP owing to the wiring harness issues.
But it's nice to know for certain which is failing.

6. And, as you noticed, SDHC support (no more el cheapo 1 and 2GB SD cards).
And FAT-32 support. Those wiil be in 7.4 (and are there in the beta test).

There's probably other usability tweaks but those are what come to mind
at the moment.

Dan

Dan Newman

unread,
Apr 9, 2013, 1:29:13 AM4/9/13
to jetty-f...@googlegroups.com
I just updated the Gen 4 / Gen 3 binaries. No change for Gen 4 actually.
But for Gen 3 there's a new EEPROM setting which controls whether the
Z endstop is treated as a MIN or MAX endstop.

In the past, the Z endstop was treated as a MIN endstop. With this update, r1003,
it is by default treated as a MAX endstop[*]. You can use RepG 40r14 - Sailfish
to change the treatment via the "endstops" tab,

https://www.dropbox.com/s/6ewz7nulb2mz796/replicatorg-0040r14-linux.tgz
https://www.dropbox.com/s/3ae8hfcp0umn0rl/replicatorg-0040r14-mac.dmg
https://www.dropbox.com/s/k8nts5l0bnzfrjd/replicatorg-0040r14-windows.zip

So, current Gen 3 Cupcake users with endstops will want to download r14 of RepG
and check (or uncheck) the "3G5D Z endstop is min" checkbox after they upgrade
to r1003 of Sailfish 4.4.

Thanks to Jetguy for helping diagnose this!

Dan

[*] The proper default is open to discussion. For historical, backwards
compatability it would make sense to have MIN be the default. However, if
most Gen 3 users will have a Z MAX endstop, then it may make sense to have
MAX be the default in deference to future users and sane usage. Comments?

Jetguy

unread,
Apr 9, 2013, 7:48:00 AM4/9/13
to Jetty Firmware
The Cupcake has either mounting point, but the real kicker here is
profile support. If you have a Cupcake, we assume you have updated to
at least a stepper extruder since you are running Sailfish because a
DC extruder cannot do acceleration and there, the entire setup is
worthless with Sailfish, You're better off staying with stock MBI
firmware sans acceleration at that point. Yes, I know you could turn
it off but, then you still have this pesky profile thing.

And with all that, the T-O-M functionality is what you are looking for
anyway. Both bots had ABPs in the end, both were designed for
endstops, both move the bed in X-Y and the nozzle in Z. Now, all you
have to do is slightly modify the start and end.gcodes in the default
sf 50 T-O-M profile if you use MAX and that's only to change the
waiting poistion into the build area. If you switch to min, then you
must use a mechanically adjustable limit switch to adjust first layer
height where as with Max, you just use the homing offset. function. We
are going to use that anyway for X and Y why not stick with the plan
for Z.

There is not a stock profile with homing to min in the first place
that I am aware of. Really, in SF 50 we have the T-O-M, Replicator,
and Replicator 2, and now the 2X. No Cupcake default is present. SO
why not set people up to use the T-O-M profile.

Which this then begs the question, how hard is it in the Replicator
series (for me the Rep1) to change to a Z max switch and have the
built in scripts use it? I mean I know how to edit the start and end
gcodes and such for Z max homing but then there still are those pesky
functions in the firmware that assume min?

On Apr 9, 1:29 am, Dan Newman <dan.new...@mtbaldy.us> wrote:
> I just updated the Gen 4 / Gen 3 binaries.  No change for Gen 4 actually.
> But for Gen 3 there's a new EEPROM setting which controls whether the
> Z endstop is treated as a MIN or MAX endstop.
>
> In the past, the Z endstop was treated as a MIN endstop.  With this update, r1003,
> it is by default treated as a MAX endstop[*].  You can use RepG 40r14 - Sailfish
> to change the treatment via the "endstops" tab,
>
>  https://www.dropbox.com/s/6ewz7nulb2mz796/replicatorg-0040r14-linux.tgz
>  https://www.dropbox.com/s/3ae8hfcp0umn0rl/replicatorg-0040r14-mac.dmg
>  https://www.dropbox.com/s/k8nts5l0bnzfrjd/replicatorg-0040r14-windows...

David Lancaster

unread,
Apr 9, 2013, 11:30:16 AM4/9/13
to jetty-f...@googlegroups.com
Shrug, I use a Z-min endstop to set a reliable starting height.  I don't even bother homing X & Y but just move the platform to center by hand.
The Z-axis is so slow on the Cupcake that I'd rather not wait for it to home to Max and back down to the build platform. I don't think there are many Cupcake users with endstops anyway, so as long as it works for Z-min, I'm happy.  

A Cupcake with Sailfish is pretty much a guarantee bastard child (past stock hardware it needs at least a 3G5D shield/hack, plus a 4th stepper driver, 4th stepper, stepper driven extruder head, etc, etc, etc), it's pretty much a "experimenter's config".  Each and every one is going to be a little different (micro-stepping, driver, stepper strength, gear ratio, etc). I would expect it to be very difficult to come up with a "just works" config that covers most setups.... I'm happy if it's tweakable and configurable enough that we can make it work, even if it does require some experimentation and research.

D.


Dan Newman

unread,
Apr 12, 2013, 12:53:52 PM4/12/13
to jetty-f...@googlegroups.com
BTW,

Last night, I posted a new rev of the 7.4 & 4.4 beta binaries. Changes are

1. on-the-fly "temp change" now works for both extruders when using Ditto Printing.

2. Previously mentioned change for Gen 3 electronics which I'll repeat here in hope
of not tripping anyone up,

----------
I just updated the Gen 4 / Gen 3 binaries. No change for Gen 4 actually.
But for Gen 3 there's a new EEPROM setting which controls whether the
Z endstop is treated as a MIN or MAX endstop.

In the past, the Z endstop was treated as a MIN endstop. With this update, r1003,
it is by default treated as a MAX endstop[*]. You can use RepG 40r14 - Sailfish
to change the treatment via the "endstops" tab,

https://www.dropbox.com/s/6ewz7nulb2mz796/replicatorg-0040r14-linux.tgz
https://www.dropbox.com/s/3ae8hfcp0umn0rl/replicatorg-0040r14-mac.dmg
https://www.dropbox.com/s/k8nts5l0bnzfrjd/replicatorg-0040r14-windows.zip

So, current Gen 3 Cupcake users with endstops will want to download r14 of RepG
and check (or uncheck) the "3G5D Z endstop is min" checkbox after they upgrade
to r1003 of Sailfish 4.4.
----------

Dan

Dan Newman

unread,
Apr 17, 2013, 1:03:30 AM4/17/13
to jetty-f...@googlegroups.com
Latest builds uploaded this evening,

1. Change temp during printing works for ditto printing.

2. When clearing the build platform, do not retract the filament for an extruder
which is not in use -- set temp of 0 -- or which has not yet reached its
target temperature. Likewise when resuming from a pause.

3. MAX31855 support for Rep 1's with ATmega 2560s. Tested and working.
Only of interest to a few individuals.

Dan

Jwo Fox-Lee

unread,
Apr 17, 2013, 2:19:09 AM4/17/13
to jetty-f...@googlegroups.com
Can you explain the P-Stop? I'm not sure what if I have it, or what it's for.
I have a TOM on MK7, currently running Sailfish 4.3 0040r11. Homes via x,y,z endstops at beginning of every print.

Thanks.

- Jwo Fox-Lee



Dan

Eighty

unread,
Apr 17, 2013, 9:57:09 AM4/17/13
to jetty-f...@googlegroups.com
I installed the latest build (r1010) this morning, and ran a test print.  Unless I've got a wonky setting (I've been tinkering a lot), I think there may be some unintended behavior.
 
The anchor drops just fine, but the anchor line quickly becomes wispy (like it's ignoring any RPM after the initial dwell).  The first part of the skirt is practically nonexistent, and eventually it catches up.
 
This 25mm diameter cylinder was printed using firmware deprime (16), 0.20mm layers, 120/150 speeds.  Default start.gcode shown below.  I don't see anything different here than before, so I assume that the new firmware changes are affecting it.  Any thoughts?

(** This GCode was generated by ReplicatorG Sailfish - 0040r15 **)
(* using Skeinforge (50) *)
(* for a Single headed Replicator 2 *)
(* on 2013/04/17 07:54:20 (-0500) *)
(**** start.gcode for Replicator 2, single head ****)
M103 (disable RPM)
M73 P0 (enable build progress)
G21 (set units to mm)
G90 (set positioning to absolute)
M104 S220 T0 (set extruder temperature) (temp updated by printOMatic)
(**** begin homing ****)
G162 X Y F2500 (home XY axes maximum)
G161 Z F1100 (home Z axis minimum)
G92 Z-5 (set Z to -5)
G1 Z0.0 (move Z to "0")
G161 Z F100 (home Z axis minimum)
M132 X Y Z A B (Recall stored home offsets for XYZAB axis)
(**** end homing ****)
G1 X-141 Y-74 Z50 F3300.0 (move to waiting position)
G130 X20 Y20 Z20 A20 B20 (Lower stepper Vrefs while heating)
M6 T0 (wait for toolhead, and HBP to reach temperature)
G130 X127 Y127 Z40 A127 B127 (Set Stepper motor Vref to defaults)
M108 R3.0 T0
G0 X-141 Y-74 (Position Nozzle)
G0 Z0.6 (Position Height)
M108 R5.0 (Set Extruder Speed)
M101 (Start Extruder)
G4 P2000 (Create Anchor)
(**** end of start.gcode ****)
CalCyl-dprm.jpg

Jetty

unread,
Apr 17, 2013, 10:40:55 AM4/17/13
to jetty-f...@googlegroups.com
The anchor drops just fine, but the anchor line quickly becomes wispy (like it's ignoring any RPM after the initial dwell).  The first part of the skirt is practically nonexistent, and eventually it catches up.

It could be that the RPM isn't as redundant as it initiially looked (I removed it was giving bad moves in queuePoint).

So we may need RPM for the anchor, and no-RPM for the rest of the print.  Time to investigate some more.

The solution may also be to change the start.gcode to remove the RPM dependency on anchors. 

Jetguy

unread,
Apr 17, 2013, 11:17:45 AM4/17/13
to Jetty Firmware
The P-stop is a triggered pause function. This way, you can design or
add a filament jam detector and any other printer sensor that can
trigger a pause.

The idea is that many folks were complaining of long prints failing
due to spool issues and the print continues "air printing". This
allows you to develop and design any number of sensors that can detect
a higher than normal force on the filament feed. Further, any number
of sensor setup described by others with everything from lasers to
high tech vision systems could be used to pause a print before actual
print failure occurs.

Simply put, it's assigned to an unused endstop and when triggered, the
machine goes into pause. Right now, only on T-O-Ms, but soon for other
bots.
> > For more options, visithttps://groups.google.com/groups/opt_out.- Hide quoted text -

Jwo Fox-Lee

unread,
Apr 17, 2013, 11:44:54 AM4/17/13
to jetty-f...@googlegroups.com
I get it now. It uses one of the extra endstop ports (x-max, y-max, or z-min) on the motherboard.

- Jwo Fox-Lee

Dan Newman

unread,
Apr 17, 2013, 12:15:34 PM4/17/13
to jetty-f...@googlegroups.com

On 17 Apr 2013 , at 6:57 AM, Eighty wrote:

> I installed the latest build (r1010) this morning, and ran a test print.
> Unless I've got a wonky setting (I've been tinkering a lot), I think there
> may be some unintended behavior.
>
> The anchor drops just fine, but the anchor line quickly becomes wispy (like
> it's ignoring any RPM after the initial dwell). The first part of the
> skirt is practically nonexistent, and eventually it catches up.
>
> This 25mm diameter cylinder was printed using firmware deprime (16), 0.20mm
> layers, 120/150 speeds. Default start.gcode shown below. I don't see
> anything different here than before, so I assume that the new firmware
> changes are affecting it. Any thoughts?

There's no new firmware changes that have any bearing whatsoever on this.
However, you used RepG 40r15 - Sailfish. That may. You can try with the
older RepG 40r14 - Sailfish and see if you see any difference.

And send me the .x3g for the two if you do and I can look.

Dan

Dan Newman

unread,
Apr 17, 2013, 12:41:44 PM4/17/13
to jetty-f...@googlegroups.com
>
> Simply put, it's assigned to an unused endstop and when triggered, the
> machine goes into pause. Right now, only on T-O-Ms, but soon for other
> bots.

Actually, it's there for all bots but Cupcakes. HOWEVER, there's an issue
on Rep 2 and Rep 2X's. Namely, no schematics and a change in pinout for
the endstops: one header appears to handle X max, Y max, and Z min. There's
pads for another header but no header. So anyone wanting to do this on a
MightyBoard RevG first needs to figure out the wiring and then solder
a connector header to their board.

Dan

Eighty

unread,
Apr 17, 2013, 4:03:02 PM4/17/13
to jetty-f...@googlegroups.com
You can try with the
older RepG 40r14 - Sailfish and see if you see any difference.

And send me the .x3g for the two if you do and I can look.

Dan
Indeed, you're right (as always).  It's in RepG.  Ran the same gcode file through RepG40r14-Sailfish to create the x3g - the anchor line and skirt are much better.  Picture attached.
 
Dan, I've attached the r14 and r15 versions so you can take a look.  As I mentioned, it was the same gcode file for both.  Thanks!
 
CalCyl-dprmr14.jpg
CalCyl-r14.x3g
CalCyl-r15.x3g

Dan Newman

unread,
Apr 19, 2013, 2:16:20 PM4/19/13
to jetty-f...@googlegroups.com

On 17 Apr 2013 , at 1:03 PM, Eighty wrote:

> You can try with the
> older RepG 40r14 - Sailfish and see if you see any difference.

Ripley's Believe it or Not! time.

The strong print line between the anchor and skirt turns out to have
been a direct effect of the bug Wingcommander identified in RepG.

The underlying gcode makes an anchor. Then it moves WITHOUT extrusion
to the start of the skirt or print. That there was extruded plastic --
a print line between the two -- was actually a bad case of stringing
caused by that bug Wingcommander found.

When Eighty saw it go away with RepG 40r15 - Sailfish, that was actually
the correct behavior (as per the gcode). It's just not what any of
us ever expected with Makerbots and RepG owing to the bug being there
who knows how long.

So this will largely be a user education issue. And, you'll have
one less piece of plastic scrap to remove from the build platform.

In the meantime, we've made all the start gcode no longer use RPM
based anchors. (Folks with 3mm extruders may find a little too big
of an anchor, btw.)

We're still deciding what to do about Jetguy's suggested new start
gcode for the Rep 1. OT1H, if we'll have a user education issue,
might as well take them all on at the same time. OTOH, there's
only so much I want to tackle in any one release.

Dan

P.S. For reference, the gcode for my M2 actually homes, squirts out
an anchor, then homes again. There's plastic connecting the "anchor"
with the start of the print unless there's really bad oozing going
on.

Eighty

unread,
Apr 19, 2013, 2:29:52 PM4/19/13
to jetty-f...@googlegroups.com
Dan,
I had guessed as much, and thanks for following up on it.
 
In the past 24 hours, I've been printing with r15-based x3g files, and it's really not a big deal.  The skirt starts out a bit light, so in order to avoid a bad first layer of the print, you'll HAVE to use a skirt.  But other than that, no big deal.
 
The only other observation is that you can't pull up the skirt by tugging on the anchor line anymore.  Now I have to use my scraper (which is a lot harder on glass and hairspray, I must admit!)

Dan Newman

unread,
Apr 19, 2013, 2:58:22 PM4/19/13
to jetty-f...@googlegroups.com
I just uploaded r1021 beta hex files. The only new feature in them is support
for a new mcode,

M322 Zzzz.zz

which tells the bot to Pause when Z = zzz.zz. It is supported on all bots.

This evening, I'll upload a RepG r16 which has support for it. Wingcommander
has preliminary support in GPX for it but hasn't yet been able to test it.
So, there's some chance you can play with it from GPX before you will be able
to do likewise with RepG.

I don't anticipate any further changes to 7.4 or 4.4 so we should be
able to release it soon after giving it a bit more time to bake.

Dan

Eighty

unread,
Apr 19, 2013, 2:59:45 PM4/19/13
to jetty-f...@googlegroups.com
Dan, can I give you a big sloppy kiss now?  THANK YOU!!!! 

Dan Newman

unread,
Apr 19, 2013, 3:04:43 PM4/19/13
to jetty-f...@googlegroups.com

On 19 Apr 2013 , at 11:59 AM, Eighty wrote:

> Dan, can I give you a big sloppy kiss now? THANK YOU!!!!

Actually, Jetty put that in last night. But, if I'm ever in New Orleans, you can
take me out for a po' boy.

Dan

Eighty

unread,
Apr 19, 2013, 3:09:11 PM4/19/13
to jetty-f...@googlegroups.com
Well then, to the both of you - Thank You!
 
And you got yourself a deal.  Not sure if you want a "true" po'boy, though.  The original version was french bread, french fries, and red gravy.  The muffaletta, on the other hand, pure genius!

Jetty

unread,
Apr 19, 2013, 3:11:46 PM4/19/13
to jetty-f...@googlegroups.com
A few things to add for this release:

1. RPM has been retired.   For the next release of Sailfish RPM is no longer supported and SF-50 is required.  (if you still need
RPM, then please use the older Jetty Firmware).  Can't see a good case for not retiring RPM as everything should
be 5D now and using stepper extruders.  If you're using Sailfish with some weird setup that requires RPM, the time is now
to let us know so we can discuss further.

2. The new Anchor (the default one in the start.gcode), looks like 4 seconds of blob after the head meets the platform,
and a very thin string from that point to the first layer in the print.  This is different from the last Beta, the last Beta had no
blob at the beginning, so the extruder wasn't primed and the first layer would have been slightly bad.

3. Regarding M322 Z?? the new Pause@Zpos command.  It's not on cupcakes because of a lack of space (but pause@zpos isn't either as there's
no LCD).    The format is M322 Z3.5  which means pause when Z position 3.5mm  is reached or higher.  You need to set it sometime after the wait
position is reached (i.e. after homing) and before the layer height you're interested in pausing at.  I.E. You could put in the 0.5mm layer, M322 Z3.5,
it doesn't have to go at the layer itself which makes it easier than finding specific points in the gcode.

Also, you can only have one M322 active at a time, they are not queued and a new one will override an old active one.
So if you need multiple pause points you put the 2nd one after the 1st one's layer height.

You still get the asterisk in the LCD display.




Jetty

unread,
Apr 19, 2013, 3:13:00 PM4/19/13
to jetty-f...@googlegroups.com
I'll skip the kiss too, no offense :-)
Po'boy sounds good for me too.

Jetty

unread,
Apr 19, 2013, 3:15:01 PM4/19/13
to jetty-f...@googlegroups.com
2. The new Anchor (the default one in the start.gcode), looks like 4 seconds of blob after the head meets the platform,
and a very thin string from that point to the first layer in the print.  This is different from the last Beta, the last Beta had no
blob at the beginning, so the extruder wasn't primed and the first layer would have been slightly bad.

And if you have a custom start.gcode, you'll want to look at updating yours to use the new Anchor method, as the old RPM method
won't break anything, but won't work correctly either with this new Beta. 

Eighty

unread,
Apr 19, 2013, 3:15:45 PM4/19/13
to jetty-f...@googlegroups.com
Oh, I do have another question while we're on the topic of a new RepG.  The revised "fill" plugin from Delsydsoftware (I think) - is that in the Sailfish version of RepG?  I don't think it is, as my latest prints haven't been generating the number of solid layers as I thought they would.  So I did the fill.py replacement in r15.  Went back and opened r14 (and didn't see the options in the profile editor).  Not sure if you even intended to bundle it in there, but FWIW, I don't think it's there. 

Dan Newman

unread,
Apr 19, 2013, 3:19:42 PM4/19/13
to jetty-f...@googlegroups.com
No it's not there. I did receive permission to include it. And it's one
of the reasons why no r16 until tonight. I need to look it over again
before dropping it in (as a replacement to the existing fill.py).

Dan

Jetguy

unread,
Apr 19, 2013, 3:27:32 PM4/19/13
to Jetty Firmware
FWIW, I ran into an issue on one of the U-T-O-Ms I built with gen4 and
Mk6.
Version 4.4 is leaving some odd extruder problems late in the print,
say around 30mm build height.
It looks to be a prime, deprime, thing?
Extruder hold is set
Test cubes look fine.
System doesn't ever skip steps, extruder isn't plugged etc.
4.4, leaves out some perimeter lines of extrusion leaving odd gaps for
no reason.
Reverting to 4.1 completely solved the issue.

I performed the following steps to ensure 4.4 was installed correctly:
re-flashed
Connected with Rep-g and reset defaults

Again, the problem here is the same SD card x3G file was printed. 4.4
prints with severe problems
4.1 prints the exact same file fine?

I will reproduce on my own bot tonight, but that came from an extended
troubleshooting session on a customer's machine.

Dan Newman

unread,
Apr 19, 2013, 3:39:52 PM4/19/13
to jetty-f...@googlegroups.com
Between 4.1 and 4.2 a tweak was made to the acceleration planner so as to
achieve more consistent speeds instead of the ramp up/down which Emmett
and others were seeing. Same issue was also causing interesting issues
on circles for which you increased the number of facets. There were no
changes to deprime handling. Just the extruder hold is all.

Between 4.2 and 4.4 there have been no changes to the acceleration planner
nor deprime handling.

So, my guess is that some higher speeds are now being hit or there's
a slight change in the character of some speed transitions. The gaps
obviously suggest an issue with the extruder. I'd experiment with
reducing the max speed changes for the extruder, reducing the max
acceleration for the extruder, reducing the max speed for the
extruder. Or, just trying the print at 66% of the speed to see
if that's even the right direction to head in.

Dan

Eighty

unread,
Apr 19, 2013, 4:37:52 PM4/19/13
to jetty-f...@googlegroups.com
Question on the M322 functionality.  If I were to insert it halfway through a fill operation on a layer where Z=14.05 (and use M322 Z14.05), would it trigger right then and there?  Or does the Z axis need to pass into that elevation for M322 to trigger?
 
I'm sure you can see where I'm going with it...I'd like to trigger a pause inside of a layer, so as to avoid external boogers from filament swaps.

Dan Newman

unread,
Apr 19, 2013, 4:45:09 PM4/19/13
to jetty-f...@googlegroups.com

On 19 Apr 2013 , at 1:37 PM, Eighty wrote:

> Question on the M322 functionality. If I were to insert it halfway through
> a fill operation on a layer where Z=14.05 (and use M322 Z14.05), would it
> trigger right then and there?

It should trigger then and there. The check is for the current z position to be >= the
requested Z value. So suddenly that requested Z value would appear and then the logic
would trigger the pause. Now, the pipeline still has to be cleared so it may not happen
for upwards of 32 moves or so.

Dan

Eighty

unread,
Apr 19, 2013, 4:49:16 PM4/19/13
to jetty-f...@googlegroups.com
Got it.  Maybe I'll put it at the beginning of an infill section, so that it'll trigger "somewhere" in there.  Shouldn't have to worry about having less than 32 moves in an infill! 

Jetty

unread,
Apr 19, 2013, 5:58:30 PM4/19/13
to jetty-f...@googlegroups.com
Or put it at the beginning of the print gcode (after the start.gcode) if it's the first pause@zpos in the print.

It behaves exactly the same as a Pause@ZPos entered from the LCD screen.

Eighty

unread,
Apr 19, 2013, 7:50:53 PM4/19/13
to jetty-f...@googlegroups.com
Right. That alone will be awesome. In this exercise, I'm trying to trigger a pause mid-way through a layer, so as to hide the transition. Don't see how it could be added at the beginning of the gcode, as the pause would be triggered when the layer began.

Jetty

unread,
Apr 19, 2013, 7:54:13 PM4/19/13
to jetty-f...@googlegroups.com
correct

Jetguy

unread,
Apr 20, 2013, 12:25:35 AM4/20/13
to Jetty Firmware
Ok, but here's the problem, feedrate was 30mm/s. You really want me to
slow down below 15mm/s?

Again, I need to do a double blind test here but I spent 2 weeks
chasing this through every single component. I then discovered I was
still running 4.2 on my personal machine. I downgraded the failing
machine to 4.1 printed the exact same file after reseting to defaults
in firmware and it prints fine. Of course I obviously want to do the
test on my personal machine but no, speed doesn't explain this.
And, I have run the machine at 120mm/s feedrate or 4X faster than the
test.BTW, the test was the "example" whistle.

Dan Newman

unread,
Apr 20, 2013, 12:32:07 AM4/20/13
to jetty-f...@googlegroups.com

On 19 Apr 2013 , at 9:25 PM, Jetguy wrote:

> Ok, but here's the problem, feedrate was 30mm/s. You really want me to
> slow down below 15mm/s?

What was the travel rates? They come into play as well.
However, the only changes in the acceleration planner are those
I described previously. No changes in the acceleration planner
after 4.2.

Dan

Dan Newman

unread,
Apr 20, 2013, 12:34:07 AM4/20/13
to jetty-f...@googlegroups.com
Also, going too slow can be a problem. If I had known it was 30 mm/s, I would
have suggested trying it at 60 or 80 mm/s. If you're printing at 30 mm/s, you may
be better off with the Jetty Firmware and turning off the acceleration planner
entirely.

Dan

Dan Newman

unread,
Apr 20, 2013, 1:35:11 AM4/20/13
to jetty-f...@googlegroups.com
> And, I have run the machine at 120mm/s feedrate or 4X faster than the
> test.BTW, the test was the "example" whistle.

On my ToM, I just printed that whistle at 100 mm/s feedrate and 100 mm/s
travel and it came out nicely. That was with the 4.4 firmware. Nothing
unusual. No gaps along the perimeter, inside or outside.

I suppose one could try using the same SD card but with SD error checking
on. Timing can be an issue with those SD cards and if there's something
borderline associated with a section of that file, then 4.1 with its
different timing might be making a difference? Pretty far fetched.

Dan

Jwo Fox-Lee

unread,
Apr 20, 2013, 4:28:50 AM4/20/13
to jetty-f...@googlegroups.com
What is the Maximum change speed you are using on the TOM?
Once I turn the speed up past 60 or so, my circles come out oval.

- Jwo Fox-Lee


Jetguy

unread,
Apr 20, 2013, 9:56:43 AM4/20/13
to Jetty Firmware
The machine that had the issue was a mega1280, mmachine is a 2560, not
that it matters. In order to properly test this, I need to crack open
mine and swap in a 1280 for a true comparison.
On my machine, both versions appear to ouput correctly, I cannot yet
explain why there was an issue on the other machine other than one
version clearly worked, the other did not. The defects occured in both
the thing lanyard loop and the main body. One thing I noticed while
printing is that the pattern of the print and the errors happend when
significant retraction was happening. In other words, printing the
whistle, the head prints the curved lower outer wall, then the ball,
then the lanyard loop, then the front short whistle top outer wall.
Those are the areas where the error was randomly happening on the
other machine.e

Unfortunately, I returned the other machine to the owner after to
reverting to 4.1 and getting successful prints.
Again, I have been unable to reproduce this issue, I'm not sure why. I
followed the standard procedures of resetting the firmware to default
values in all cases just to make sure when troubleshooting the other
machine before reverting to older firmware.
It could be a machine issue, I just find it odd to be have such a
major difference in results.

Dan Newman

unread,
Apr 20, 2013, 11:15:12 AM4/20/13
to jetty-f...@googlegroups.com

On 20 Apr 2013 , at 1:28 AM, Jwo Fox-Lee wrote:

> What is the Maximum change speed you are using on the TOM?

I use 30 mm/s for X & Y max speed change. I also have a somewhat
customized tom with an X carriage with only three sets of linear
bearings instead of the stock four bushings. But I print at feedrates
of 120 mm/s on it without any issues. I only did that particular
whistle at 100 mm/s since I didn't want the internal ball breaking
loose. Before I had acceleration, I used to have issues printing
it at 30 mm/s owing to that issue. I was somewhat pleased that it
printed without a problem at 100 mm/s (with acceleration).

Dan

Dan Newman

unread,
Apr 22, 2013, 6:32:20 PM4/22/13
to jetty-f...@googlegroups.com
For those who noticed, the r1027 Replicator hex files posted last
night was the change to make filament load/unload and jog appear
during a cold pause. No other changes.

The r1029 ToM and Cupcake hex files posted today are a minor
change which only impacts Cupcakes. When resetting the
eeprom to factory defaults, the new Z endstop setting for
cupcakes was not being set with a default value. No other changes.

Dan

Dan Newman

unread,
Apr 24, 2013, 11:14:27 PM4/24/13
to jetty-f...@googlegroups.com
FWIW, I just posted r1031 for Replicators. It has the cancel menu available while
paused as per Eighty's suggestion / request. I am expecting this to be the last change
and hope to announce in a day or two that 7.4 and 4.4 is released.

Thanks,
Dan
Reply all
Reply to author
Forward
0 new messages