@dc42 said in M106 is executed out of order when printing over USB:

My guess is, when printing over serial, movement commands are queued, but control commands are not. This causes them to be executed ahead of the movement by the size of the movement queue.

Correct. I have corrected the documentation.

Thank you very much for updating documentation. Now it matches the behavior I'm observing exactly.

However this raises a follow up question: is there any workaround besides putting a gcode file on the SD card? The inconsistent queueing is detrimental to printing bridges, which in my experience always require high airflow to avoid sagging. This puts print-by-wire at a significant disadvanage.

My setup is pretty rudimentary. I don't have an LCD, there is only one SD slot which is occupied by an SD card holding RepRap configuration, and the only way to connect to the printer is USB. My only option seems to be using M28 and friends, but 1) I'm yet to make this work due to issues in Octoprint (it fails to recognize the success response from RepRap's M21), and 2) the general consensus is that M28 is inherently very slow anyway.

my menu files are here:
https://ufile.io/9anizm85
(forum does not allow zip uploads)

@nikscha I'm a bit confused by the term constant current? Isn't that the regular mode and the G1F-value indicates the speed?

I'm currently playing with a BLDC motor in constant torque mode. It is controlled by simpleFOC and their step/dir interface.
They also support stepper motors and have the option to read out shaft_velocity in rad/s. This value can be multiplied by 9.55 to get RPM.

@nikscha See https://docs.duet3d.com/en/User_manual/Reference/Gcodes#custom-gcodes

Ian

@hpiz both duet3 6HC and duet 3 mini 5+ have a VFD header. 6HC next to the erase header , mini close to the middle of the board.

See the wiring diagrams at https://docs.duet3d.com/en/How_to_guides/Wiring_your_Duet_3

and https://docs.duet3d.com/en/User_manual/Machine_configuration/Configuration_CNC#connecting-a-spindle

for more details.

@ThorAK77 best just use bossa and go directly to 3.4.6 https://docs.duet3d.com/en/User_manual/RepRapFirmware/Updating_firmware#all-other-duet-boards

@JRDM I guess you can use conditionals in the macro or start/stop the second stream from within the first stream. But I haven't tried it.
There is this article Duet3 Wiki that might help you.

@dc42 does that sound possible?

@oliof last time I looked, Marlin used fixed width fonts, although that might have changed by now. RRF uses proportionally spaced fonts.

@deckingman

thank you for the input, i will give it a try

@OwenD

I have opened a FR on github for this: https://github.com/Duet3D/RepRapFirmware/issues/891

T3P3 created this issue in Duet3D/RepRapFirmware open [FeatureRequest]: Timeout on M291return default value #891

@gloomyandy Maybe I'm wrong? I was under the impression, all Cortex M0+ MCUs are dual core...

I already have this working. It saves babystep value on pause, cancel, print end and loads it at print start.

G32 and G29 resets it to 0.

It's also possible to continously monitor it with daemon.g in case of event of power loss.

@marvineer You don't really need to test for each one, just test for one of them and groupe then creation/setting together...

if !exists(global.global1) global global1 = {1, 2, 3} global global2 = {3, 4, 5} global global3 = "whatever" else set global.global1 = {1, 2, 3} set global.global2 = {3, 4, 5} set global.global3 = "whatever"

Also if these globals are in effect constants (so nothing anywhere else changes the value), then there is no need to set the value if the global(s) already exist.

@gloomyandy I'm collecting telemetry every 10 secs so yeah, that definitely puts Duet under stress.

Re collecting the M122 data. Is there any docs for the Software reset code Error status and Aux0 errors ? I would like to understand the meaning of the reported vars

=== Platform === Last reset 17:44:30 ago, cause: power up Last software reset time unknown, reason: User, Gcodes spinning, available RAM 2276, slot 0 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a Error status: 0x00 Aux0 errors 0,0,0

Note This was taken just now and without any OOM

@deckingman said in Add offset to reported Vin similar to M912:

@gloomyandy Dunno. I thought I read somewhere that it does but maybe not?

Just reads. By default only every 10 seconds. If you need more, use a loop within. You'd have to get pretty crazy to cause a performance issue.

@shugo1110 said in [Possible bug] Params parsing:

With the current allowed-chars-list i get an error when i do a

M98 P"0:/anymacro" S-1

That's a bug - thanks for reporting it. Workaround: use S{-1}.

until this fix i also could do a

M98 P"0:/sys/home.g" XYZ

this is resulting in an error now.

That's intentional. In most contexts, parameter letters must be followed by a value for that parameter. Older versions of RRF assumed a zero value if none was given, but that sometimes made it harder to diagnose what was wrong in the command line.

@dc42 wanted to follow-up on this issue to see if it will make 3.5? I couldn't find the issue on github.. Thanks

The point is to avoid daemon.g and globals due to the side effects (SD card wear and delayed reaction to changes).

An SBC plugin would be an interesting first approach. It might even be one where I would consider SBC mode useful ...

@Thorpydo
Hmmm, the RJ11 connector is made to accept one wire per pin, and it gets inserted instead of crimped.
How best to handle the junction here?

@dc42 I've made some tests according to what @sinned6915 said and I have to say he's saying something. There's a minimum movement distance to actually get the commanded distance.

I've attached a dial indicator to measure Z axis movement then moved the Z axis up-down-up-down.

If I move the Z:

0.01 : I get no movement 0.02 : dial moves less than 0.01 both directions
But here comes the interesting part, if I move Z: 0.05 : I get 0.03, like 0.2 is deducted from it. 0.07 : I get 0.05 0.09 : I get 0.08 only 0.1 gets deducted

And it seems that from 0.125 I actually get the right movement distance that had been commanded.

Considering this there are two options

I probe with 0.05 dive height hoping that the backlash is equal among all the probing moves (I assume it is because I don't se issues on my prints with 0.05 Z-Hop, but testing it now with 0.15) or I set the dive height to 0.125-0.15 which is still pretty low and gives true movement distance.

I would chose the latter.