Motion Controller FW Version 1.1.6-rev1?

Discussions about ideaMaker and other printing software.
Tinkerer
Posts: 176
Joined: Mon Oct 09, 2017 8:30 pm
Location: Germany

Motion Controller FW Version 1.1.6-rev1?

Postby Tinkerer » Mon Nov 13, 2017 12:37 pm

Hi All,

just noticed there is a new Firmware for the motion controller board available on the raise3d-website since Nov. 2.nd.

Anybody tried it already? Any experience (positive or not;-)?
...there's nothing like the smell of fresh ABS in the morning...

Jetguy
Posts: 2470
Joined: Tue Mar 22, 2016 1:40 am
Location: In a van, down by the river

Re: Motion Controller FW Version 1.1.6-rev1?

Postby Jetguy » Mon Nov 13, 2017 1:40 pm

Update it. That's all that needs said.

Jetguy
Posts: 2470
Joined: Tue Mar 22, 2016 1:40 am
Location: In a van, down by the river

Re: Motion Controller FW Version 1.1.6-rev1?

Postby Jetguy » Mon Nov 13, 2017 2:37 pm

Sorry if I'm frustrated, I just said this on Thursday last week. viewtopic.php?f=3&t=4471&p=21016#p20965

At the same time, finally, after months and months we have an actual marlin update. Please run that latest firmware- especially if you want to pause and change filament or do any extended pauses (although any pause over 60 seconds is an issue on firmware 1.1.1).

Tinkerer
Posts: 176
Joined: Mon Oct 09, 2017 8:30 pm
Location: Germany

Re: Motion Controller FW Version 1.1.6-rev1?

Postby Tinkerer » Mon Nov 13, 2017 3:08 pm

Jetguy wrote:Sorry if I'm frustrated, I just said this on Thursday last week. viewtopic.php?f=3&t=4471&p=21016#p20965

At the same time, finally, after months and months we have an actual marlin update. Please run that latest firmware- especially if you want to pause and change filament or do any extended pauses (although any pause over 60 seconds is an issue on firmware 1.1.1).


Jetguy,

I do not exactly understand whether my question was the reason why you are frustrated?
...there's nothing like the smell of fresh ABS in the morning...

Jetguy
Posts: 2470
Joined: Tue Mar 22, 2016 1:40 am
Location: In a van, down by the river

Re: Motion Controller FW Version 1.1.6-rev1?

Postby Jetguy » Mon Nov 13, 2017 3:16 pm

That both users and Raise 3D have not said more about how important this update is.

Jetguy
Posts: 2470
Joined: Tue Mar 22, 2016 1:40 am
Location: In a van, down by the river

Re: Motion Controller FW Version 1.1.6-rev1?

Postby Jetguy » Mon Nov 13, 2017 3:17 pm

Put it this way, saying that 1.1.1 has a bug is taboo. Fixing that bug and then saying please update- appears to be taboo.

Tinkerer
Posts: 176
Joined: Mon Oct 09, 2017 8:30 pm
Location: Germany

Re: Motion Controller FW Version 1.1.6-rev1?

Postby Tinkerer » Mon Nov 13, 2017 3:34 pm

Well, to be honest I have found the update by chance, I was looking for something completely different.
And then I did a search in the forum for "Motion Conrtroller Firmware 1.1.6" - and was surprised to find
little to nothing...

Looking at the release notes I thought this might be a good idea to install...:

Version 1.1.6-rev1 - November 2, 2017

Add history tracking into thermal runaway function
Reimplemented thermal runaway function, added protection while changed by gcode
Temperature reporting during heating period fixed
Enlarged thermal runaway protection range to fix the thermal error on certain machines
Add extruder number while throwing out max or min temperature error to help identify the corresponding thermalcouple
Add compile option for single extruder. (uncomment #define DUAL to get dual head version.) In case to avoid the damaged second thermocouple on single head machine to generate an error
Modified M112 kill function to implement fast stop feature

What I'd be interested in would be users experiences -
any changes in operation observed?

I also would be interested to get more infos/details about the changes from our Raise3D-friends.
In which way do the changes prevent thermal runaway?
Are the mods discussed in this forum reg. thermal runaway not needed anymore?
Is this device no safe to run unattended?
Can I get rid of the fire extinguisher beneath my printer now?
...
...there's nothing like the smell of fresh ABS in the morning...

Jetguy
Posts: 2470
Joined: Tue Mar 22, 2016 1:40 am
Location: In a van, down by the river

Re: Motion Controller FW Version 1.1.6-rev1?

Postby Jetguy » Mon Nov 13, 2017 3:38 pm

There are no changes in operation. None, it's just a minor update to the motion control. Same Marlin base code, same basic motion settings, just a couple of fixes.

Clearly I have failed to educate the masses on the thermal runaway. It's a failure on my part to make this clear enough that everyone understands.
Things like saying no firmware update can detect a condition (cable unplugged) if the hardware itself cannot detect a change in state- did not reach all members or make them understand.

Tinkerer
Posts: 176
Joined: Mon Oct 09, 2017 8:30 pm
Location: Germany

Re: Motion Controller FW Version 1.1.6-rev1?

Postby Tinkerer » Mon Nov 13, 2017 3:44 pm

Oh, I have read the discussions reg. thermal runaway and I understand the importance of this quite well.

I can imagine multiple HW-changes to make it possible to detect a broken wiring -
I guess there was some suggestion already in some thread...

Maybe someone from Raise3D could comment on the questions I wrote in my earlier post?

Why not tell us clearly what conditions now can be safely detected and which conditions the user
has still to be "aware" of?
...there's nothing like the smell of fresh ABS in the morning...

Jetguy
Posts: 2470
Joined: Tue Mar 22, 2016 1:40 am
Location: In a van, down by the river

Re: Motion Controller FW Version 1.1.6-rev1?

Postby Jetguy » Mon Nov 13, 2017 5:11 pm

resistor modification details viewtopic.php?f=4&t=3524&p=19044&hilit=resistor#p18989

Discussion point viewtopic.php?f=2&t=4348&p=20912&hilit=resistor#p20912
Again, here is the recommendation:
#1 secure the cable so it cannot come unplugged.
However, please note, without the resistor mainboard mod- a failure of the cable still can happen. Again, if your glue or cable tie or the cable itself fails still = problem. You reduced the risk but did not eliminate it.
#2 When you apply the resistor mod to the mainboard, now the very mainboard itself is capable of detecting a connection fault to the head breakout and "fails safe" in that a high temp is read when the cable is unplugged or broken. Again, we are applying a failsafe mod to the very mainboard itself since this is what controls the heater. When used as a pair (both a mechanical fixing of the cable and connectors, and the resistor mod) you have layers of security. You should not have a cable failure but if that still happens, now, beyond a shadow of doubt, the mainboard can detect this failure.


Without a (hardware) change, there is no way code (firmware) can detect this state of error. If your PID is properly tuned, your system is printing and the last reported temp is perfectly normal but say 2C under the set temp, the heater will be in the on state because you are trying to reach the setpoint. If the (ribbon) cable comes unplugged in this state, the last temp keeps being read as if it's being updated even though the cable is physically not plugged in. As such, the heater cannot be controlled because the logic is being fed bogus information. This is why this requires a hardware fix- a set of resistors that change the voltage on the pin should the cable come unplugged. That way, the very hardware system only works if the cable is working as a system.


To answer your question, what can be detected?
The AD597 thermocouple amp on the breakout board can detect if the thermocouple itself goes open circuit (broken wire, not connected at screw terminals on breakout). This has always been in place. It requires no firmware as by default the condition turns the heater off instantly.
Again, first layer is the connection from the very temp sensor (thermocouple) to the extruder head breakout screw terminal.
This connection can detect a fault and does not require firmware to do that.

What cannot be detected (due to hardware limitations) or requires layered assumptions:
If the thermocouple temp sensor separates physically from the heater block or fails mechanically inside (thermocouple comes apart) then it is no longer sensing the actual temperature of the heater block and thus the heater itself. To catch this state, you depend on either things we do not have (second temp sensor) or try to make logical sequence based decisions (if heater is on, temp should rise by X degrees in Y time period). That is literally what the safety code is doing. EXCEPT- within 10C of the setpoint, your PID tuning kicks into the heater controller state code. Once in this range, the percentage on of the heater is less as you near the setpoint (The "P" for proportional). As such, a rule based on heater on 100% rises 1C in X time period is not valid. Again, just understand the controller logic here. If the reported temp is greater than 10C difference (lower) than the setpoint temp, then the heater is on 100% full blast maximum power. As the reported temp nears closer to the setpoint temp, at 10C different PID code begins to reduce the PWM ON state of the heater. However, at 10-5C range, the heater is on more than steady state temp (temp is rising and rising fast) in order to actually reach the setpoint. This is the danger zone because if the controller gets bad temp readings that are not the actual real hardware extruder temp it means the heater is ON and rising in temp uncontrolled.

If the ribbon cable between the breakout board and mainboard fails or comes unplugged- the stock mainboard does not detect this fault.

Hence, they said this in the update notes:
Add history tracking into thermal runaway function
Reimplemented thermal runaway function, added protection while changed by gcode
Temperature reporting during heating period fixed
Enlarged thermal runaway protection range to fix the thermal error on certain machines


The firmware 1.1.1 has all Marlin Thermal Runaway protection disabled. Then I made the suggestion and several others followed to at least enable that basic code. Then updates were made to the firmware and folks used this. And some had problems and some printed just fine all day long. Again, understand, I did not write the safety code, my comment was, it exists in the firmware source code and was not enabled. I simply said we should try enabling it. Some people had no issues at all, others kept getting stopped prints when the safety code kicked in. So, Raise 3D reverted back to 1.1.1 firmware without the code enabled and that is why 1.1.1 has no thermal runaway protection. Over time, the open source community and fellow members looked more into the false triggers and other problems in the safety code and suggested changes that have resulted in firmware 1.1.6. Examples fixed were that a change in temp commanded by gcode greater than the safety range could make the system think it was in fault. Now that is fixed.
The key here is, look at what the safety code is looking at:
https://github.com/Raise3D/Marlin-Raise ... guration.h


/
/===========================================================================
//============================= Thermal Runaway Protection ==================
//===========================================================================
/*
This is a feature to protect your printer from burn up in flames if it has
a thermistor coming off place (this happened to a friend of mine recently and
motivated me writing this feature).
The issue: If a thermistor come off, it will read a lower temperature than actual.
The system will turn the heater on forever, burning up the filament and anything
else around.
After the temperature reaches the target for the first time, this feature will
start measuring for how long the current temperature stays below the target
minus _HYSTERESIS (set_temperature - THERMAL_RUNAWAY_PROTECTION_HYSTERESIS).
If it stays longer than _PERIOD, it means the thermistor temperature
cannot catch up with the target, so something *may be* wrong. Then, to be on the
safe side, the system will he halt.
Bear in mind the count down will just start AFTER the first time the
thermistor temperature is over the target, so you will have no problem if
your extruder heater takes 2 minutes to hit the target on heating.
*/
// If you want to enable this feature for all your extruder heaters,
// uncomment the 2 defines below:

// Parameters for all extruder heaters
#define THERMAL_RUNAWAY_PROTECTION_PERIOD 40 //in seconds
#define THERMAL_RUNAWAY_PROTECTION_HYSTERESIS 8 // in degree Celsius

// If you want to enable this feature for your bed heater,
// uncomment the 2 defines below:

// Parameters for the bed heater
#define THERMAL_RUNAWAY_PROTECTION_BED_PERIOD 40 //in seconds
#define THERMAL_RUNAWAY_PROTECTION_BED_HYSTERESIS 4 // in degree Celsius


So again, what does this mean?
Well, it means the firmware is assuming it is getting a good reading from the thermocouple. In the event of the ribbon cable coming unplugged on stock mainboard without the resistor mod- the same last temp just keeps being read. That means that if that last temp was within the 8C "window" of the setpoint, this safety code will never catch this now very dangerous condition.

Again, you are printing. The motion of the extruder head and constant flexing of the ribbon cable either has it fail or becomes unplugged (this is one connector without a lock). In this state, a stock system unmodified will potentially and can be demonstrated, will then keep reporting the last temp at a hardware level to the processor and thus the firmware. Since it happened mid print- the most likely answer is the last temp was well within the 8C window and thus the firmware and safety code will not invoke. Again, if the last reported temp was lower than setpoint the firmware is trying to raise the temp to the setpoint, the heater will be in the ON state and PWM controlled based on the "P" proportional difference between the current temp and the setpoint. Depending on how accurate your PID tuning was, we now have a state where the heater is some percentage on, and either the losses allow the heater to keep getting hotter with a constant power input, or falling. Either way, bad for printing. you are in an uncontrolled state, the heater rises or falls in temp without any correction. The hardware mainboard thinks it is getting a reasonable temperature report It's perfectly normal. It's not inside the safety code triggering range. Bottom line, safety code will not detect this type of fault and my personal gut feeling is, this fault may happen a LOT and be completely unknown to users but explains some print problems. However, if you go to source code here and tighten up the safety code range to a lower value, it's more likely than not in a normal print without a fault- you may trigger the safety code and be quite frustrated. Again, the changes and fixes were to enable the safety code but also try to ensure folks did not get tripped in edge conditions and thus be angry and revert back to no safety code. It does not mean that the firmware has anything to do with this hardware "limitation" of the ribbon cable.

firesped
Posts: 836
Joined: Mon Mar 21, 2016 9:23 pm
Location: Tucson, AZ

Re: Motion Controller FW Version 1.1.6-rev1?

Postby firesped » Mon Nov 13, 2017 11:48 pm

if we want to get technical. raise3d actually needs to have 1.1.1 be the main firmware posted on GitHub as that is their primary standard firmware. 1.1.6-rev1 needs to be a branch of that.

However, I have not looked at the 1.1.6-rev1 firmware but I think that is the one that has been posted for a long time. It still has bad code on the thermal protection process.
RL name: Michael Nolen
printers:
raise3D N2 kickstarter Early Bird
Trinus Deluxe (running smoothieware on Azteeg X5 GT board)
Monoprice Maker Select v2

firesped
Posts: 836
Joined: Mon Mar 21, 2016 9:23 pm
Location: Tucson, AZ

Re: Motion Controller FW Version 1.1.6-rev1?

Postby firesped » Tue Nov 14, 2017 12:01 am

to note that I went to great lengths to build a version with massive debugging code on the whole process and located the issue and fixed it.

the problem has to due with the states getting passed correctly to the right state. the solution was to updated the code from marlin 1.0.6 to the code found in the marlin 1.1.1 release client. Note that raise3d firmware 1.1.1 is not marlin 1.1.1 but marlin 1.0.6.

I have an updated version of the firmware as a fork. which I dubbed v1.1.7 located here. https://github.com/Firesped/Marlin-Rais ... tree/1.1.7

It actually an update to 1.1.6-rev2 which added the lack of material code for the filament runout sensor.

1.1.7 added my code for the F command to turn off and on the FRS and change the open or closed states of the endstops on the FRS.
RL name: Michael Nolen
printers:
raise3D N2 kickstarter Early Bird
Trinus Deluxe (running smoothieware on Azteeg X5 GT board)
Monoprice Maker Select v2

firesped
Posts: 836
Joined: Mon Mar 21, 2016 9:23 pm
Location: Tucson, AZ

Re: Motion Controller FW Version 1.1.6-rev1?

Postby firesped » Tue Nov 14, 2017 12:07 am

wish they had documented what they changed in M112. if I knew what it was doing, I could fix this in the 1.2.2 version.
RL name: Michael Nolen
printers:
raise3D N2 kickstarter Early Bird
Trinus Deluxe (running smoothieware on Azteeg X5 GT board)
Monoprice Maker Select v2

User avatar
Vicky@Raise3D
Posts: 3612
Joined: Fri Mar 25, 2016 3:54 am

Re: Motion Controller FW Version 1.1.6-rev1?

Postby Vicky@Raise3D » Tue Nov 14, 2017 8:46 am

firesped wrote:wish they had documented what they changed in M112. if I knew what it was doing, I could fix this in the 1.2.2 version.


The M112 was designed to be emergency stop code to work with Fast Stop function. But we achieve the Fast Stop function without M112, so we comment it.


Return to “Software”

Who is online

Users browsing this forum: Bing [Bot] and 2 guests