Software package 3.3-rc2 released

EducatingSavvas

@dc42 said in Software package 3.3-rc2 released:

EDIT: I have just updated those binaries to fix M4 as well.

That seems to work now - although I'm not aware of any CNC platforms using g-code in that way. Normally the tool is specified with T followed by the number in the software's tool database. I am planning to have three tools on my CNC machine - one router spindle, a diode laser and a tangential knife. Are there any particular advantages for the change?

BoA

I noticed a strange behavior after I updated from 3.2.2 to 3.3RC2.

I have a filament presence switch that I use for triggering filament load macro.
After I updated to 3.3RC2 it seems to be a lot of false triggers.
Powering up printed, it does nothing for about 3 minutes and suddenly starts triggering and display messages:
Error: Attempting to extrude with no tool selected.

I do not need to start print or do anything. Just power on printer and wait.

Duet3 standalone setup.

My config files:
trigger3.g
config.g
fs_enable.g
fs_disable.g
fs_config.g

oozeBot

We need to report a significant issue in 3.3-rc2 when using a 6HC with attached SBC.

When canceling a print, "stop.g" is called, not "cancel.g" like in previous versions of the firmware. This was validated by putting M291 P"Stop" at the top of stop.g and M291 P"Cancel" at the top of cancel.g.

dc42

@boa said in Software package 3.3-rc2 released:

I noticed a strange behavior after I updated from 3.2.2 to 3.3RC2.

I have a filament presence switch that I use for triggering filament load macro.
After I updated to 3.3RC2 it seems to be a lot of false triggers.
Powering up printed, it does nothing for about 3 minutes and suddenly starts triggering and display messages:
Error: Attempting to extrude with no tool selected.

I do not need to start print or do anything. Just power on printer and wait.

Duet3 standalone setup.

My config files:
trigger3.g
config.g
fs_enable.g
fs_disable.g
fs_config.g

I doubt that this has anything to do with firmware changes. I think your filament out switch is getting triggered, or picking up interference, or has a bad connection. You enable it in config.g but your trigger3.g file doesn't check whether there is a current tool, or that a file is being printed and has not been paused.

dc42

@oozebot said in Software package 3.3-rc2 released:

We need to report a significant issue in 3.3-rc2 when using a 6HC with attached SBC.

When canceling a print, "stop.g" is called, not "cancel.g" like in previous versions of the firmware. This was validated by putting M291 P"Stop" at the top of stop.g and M291 P"Cancel" at the top of cancel.g.

Thanks, I've asked @chrishamm to take a look.

BoA

@dc42 I would think that is the case if such behavior was also on 3.2.2, but with 3.2.2 it works just fine without false triggers.

dc42

@boa said in Software package 3.3-rc2 released:

@dc42 I would think that is the case if such behavior was also on 3.2.2, but with 3.2.2 it works just fine without false triggers.

Have you tried switching between 3.2.2 and 3.3RC2 more than once? It wouldn't be the first time that the first appearance of a problem caused by a bad connection happened to coincide with a firmware update.

BoA

@dc42 Yes. Reverting to 3.2.2 fixes that strange behavior. I tried 3 times. I did not try intermediate versions to identify which one introduces that.

Edit: This behavior is in 3.3beta1

chrishamm

@oozebot said in Software package 3.3-rc2 released:

We need to report a significant issue in 3.3-rc2 when using a 6HC with attached SBC.

When canceling a print, "stop.g" is called, not "cancel.g" like in previous versions of the firmware. This was validated by putting M291 P"Stop" at the top of stop.g and M291 P"Cancel" at the top of cancel.g.

Thanks for your report, I've got a fix ready for this.

dc42

@boa I am trying to reproduce your issue. So far the trigger hasn't gone off; but I have nothing connected to IO8_IN. What type of filament switch is it? Is is closed when filament is present, and open when it is not; or the other way round? Do you have filament in in when this issue occurs?

dc42

For those testing with 3.3RC3 the latest firmware binaries are at https://www.dropbox.com/sh/duc057ejldxhl48/AADiuF-oiz9EmkFX6HCeodxTa?dl=0. The change list since the 3.3RC2 release is https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta-&-RC#reprapfirmware-33-post-rc2.

dc42

@dc42 said in Software package 3.3-rc2 released:

@boa I am trying to reproduce your issue. So far the trigger hasn't gone off; but I have nothing connected to IO8_IN. What type of filament switch is it? Is is closed when filament is present, and open when it is not; or the other way round? Do you have filament in in when this issue occurs?

My test system has been sitting for almost 9 hours, and still no false triggers.

Serbitar

@dc42 will these soon be pushed to the apt repos?

BoA

@dc42 This is just a transoptor (Prusa MK3S filament sensor). I just disabled it for now. Not essential feature as I am using magnetic filament monitors. It was used only for loading filament. I have filament loaded when I can see false triggers - no light is going through sensor, so output is in low state.

dc42

@boa said in Software package 3.3-rc2 released:

@dc42 This is just a transoptor (Prusa MK3S filament sensor). I just disabled it for now. Not essential feature as I am using magnetic filament monitors. It was used only for loading filament. I have filament loaded when I can see false triggers - no light is going through sensor, so output is in low state.

Thanks. I'll re-run my test with io8.in connected to ground.

dc42

@boa, I left my machine on for 9 hours with io3.in connected to ground, and I didn't see any false triggers. So I am fairly sure that the issues you are seeing are caused by noise pickup or that the sensor is generally producing spurious triggers. It may be that RRF 3.3 response to noise pulses faster than previous versions, because the loop that polls the triggers is no longer responsible for managing motion, so it may execute faster.

If the sensor cable run close to a stepper motor cable, and the false triggers only occur when that stepper motor is energised, then it may be that the sensor cable is picking up inductive interference from the stepper motor cable.