Topics created by curieos

@chrishamm I bumped it up to what I believe is the max, 115200, and it's still inconsistent.

I believe I have replicated it. I put M400s and echos into the pause and resume macros to get more useful information about user and machine position, but I think the M400s caused the issue to not happen.

It appears to occur regardless of how the machine is paused (filament monitor error or manual pause), or which interface resumes it. It appears that all it takes is one pause on the secondary tool. The ones I'm producing currently are small but noticeable, and don't occur without a pause. I believe multiple pauses create a larger shift.

I've confirmed pauses while the primary tool is active do not cause the shifting. I've also confirmed adding an M400 to the end of the resume.g file prevents this shift.

Configuration repo

@timschneider No, there are retractions in the pause and tool change files, but we do not use M207 and G10/11.

@curieos I've got new builds ready for testing, please DM me if you wish to try them as well (with 3.5.2). I expect they'll be public sometime next week.

@chrishamm Was xscreensaver installed on the older bullseye image? I'll give that a try when I get into work later, thanks!

@curieos said in M116 Hanging after M568 Error:

@dc42 This is in SBC mode, can I just upload these to the FW directory and send the update commands?

As you have already installed 3.5.0-rc3 from the package server, yes you can. However, to get the full fix you will need a DSF update too. We expect to release rc4 very soon.

@curieos I'm glad you appear to have found the cause! Ground loops can cause various odd behaviour, just like ESD can.

I'll mark this thread as solved but feel free to revert it if the problem recurs.

@curieos
Gotta run it?

@curieos said in M911, Print not Resuming After Voltage Threshold is Reached:

That is highly unlikely, the buffer provides enough power for the M911 codes to be run to completion

Sorry, I forgot:

this is supposed to be a large, industrial machine that offers power loss recovery as a selling point.

As a Pro, you sure have monitored the 24V and 3.3V rails’ behaviour on the event of sudden power loss - a cheapo two-channel scope is all you need. What I know for sure is that the resume.g file is generated by RRF on an undervoltage event as long as the Duet’s electronics have sufficient power to stay alive long enough. And I can assure you: 4 secs are long enough.

OTOH, your 3-4 seconds buffer supplies 22V, so it is meant to feed all steppers and heaters (excluding the bed) as well? These devices are operated by strong pulses - a voltage plot over these 3-4 secs might be interesting 😊

@curieos Conditional G-code is known to be relatively slow in software v3.4. I suggest you upgrade to v3.5 ASAP, because that should be significantly faster.

@curieos said in 6XD 5V Input Voltage Limits:

If the 5V supply in question were adjustable, and the 6XD were to allow some fraction of a volt over 5V, would it be possible to overcome the voltage drop from the protection circuitry?

Yes. The protection circuitry comprises a Schottky diode between 5V_EXT_IN and the 5V_EXT supply that you can pass to the Pi. This will drop around 0.4V. So you will need to provide about 5.6V from your PSU. Take care not to exceed 5.7V.

@curieos said in Save/Recall Heater State:

I'm not sure, I had some concern about changing values that aren't necessary to be changed. It feels like bad practice, but I can't think of a real problem it would cause.

It will not cause any problems if my experience, using firmware 3.4.6, is any indication and I use variables extensively, both local and global. Currently on my 4 tool printer I have 70 some global variables and many things get updated in a group regardless of how many values within that group may actually have changed. No problems to date.

Frederick

@oliof said in "Safe" Z Probe:

@fcwilt if you set the Z axis values to 0:25 rather than 175:200, does the behavior improve? if yes, maybe there is an issue in how rrf determines the maximum length moved before aborting the homing move.

I will perform that test after diner and post back here.

Frederick

@Falcounet Alright, thanks!

@dc42 Okay, thanks for the insight, I'll look forward to that lower current model!

@OwenD Yes! I didnt noticed the typo either. Ok, will add this and try it further but question remains regarding why is this happening, it started after falshing the new raspi image and version 3.5.2. Can you confirm there should not be a problem using the 64 bit version on my raspi? because there are other problem like for example DWC not starting on my touch screen, there is just a linux desktop instead (DWC working through web interface conncection)

@dc42 Does feedforward only work in job files? Should I expect it to work in macros or via the interface buttons?

@curieos Please send me an email with a link to your dump (e.g. Google Drive or Dropbox) to christian@duet3d.com and I'll have a look at it.

@chrishamm Thanks, wasn't sure if this was a "solve it in linux" issue or a problem to solve in DSF.

@curieos I found the answer to my own question. https://docs.duet3d.com/User_manual/Reference/Gcodes#m563-define-or-remove-a-tool I can use the L parameter to set which drive to map filament to.

@Phaedrux It's working now. Not sure what changed, but I did put it in a slightly different place this time.