Topics created by NineMile

@chrishamm Just saw your fix for this (and the changes for my M291 J2 PR, thanks 👍)

Just thinking about this, it might also make sense to add g68Centre[0] = g68Centre[1] = 0.0; as well where the angle is reset in G69 - it is not possible to specify G68 without X and Y axis co-ordinates so keeping the centre defined and visible in the object model doesn't make much sense.

Implemented limit checks and machine position calculation so the moves work properly, this is how it works in practice: video

@gloomyandy said in MQL System with Diesel Heater Pump:

@NineMile Have you tried doing 1-5Hz just using M950?

I have a basic implementation of this now that uses M950 for anything equal to or over 1Hz, and then for anything lower I use daemon.g to run the on/off cycle, which seems to work nicely.

@chrishamm Gotcha. Thanks for the info 👍

@NineMile please create a feature request for this on the Github Issues page of the RepRapFirmware project.

@NineMile I just tried this with DWC/RRF 3.5.2, toggled the 'Do not close error message automatically' to off, then provoked an error that displayed a red box. Like when a blue or green message box pops up, the red box had a white progress bar at the top of it, and disappeared once that completed. Also tried changing the notification period, and that worked too.

I've noticed a couple of people have had problems with their DWC settings. Refreshing these seems to resolve some issues. Whether this is because the format of the dwc-settings.json has changed over time, or the file has become corrupt and not writeable, I'm not sure. Try renaming sys/dwc-settings.json to something different (eg .old on the end), and refresh the browser. Edit something, eg set 'Do not close error message automatically' to off, to create a new dwc-settings.json, and see if that resolves the problem.

Ian

Just wanted to update to say I've been using daemon.g to control my VFD over modbus for a while now and it feels like it's working well. The error messages not being suppressed when writing to a variable is a bit of a pain but aside from that, it feels like a relatively robust way to do it.

For clarity, I still have the spindle configured to use enable / direction / PWM pins but these are not connected. I read the spindle state in daemon.g and send the relevant Modbus requests to start it and control the speed.

I've had a 2 second comms timeout set on the VFD so if there's no Modbus status check within 2 seconds the VFD will stop automatically.

There's a lot of functionality I could add to this to e-stop / pause / whatever if the VFD reports the spindle stopped or at high load or is completely unresponsive, but for the moment I'm pretty happy with the behaviour.

@timschneider Thanks for this - I haven't quite decoded how the 3-wire setup works on my particular VFD yet but when I do, I might give it a shot.

@NineMile most if not all of the relevant real thunder changes in terms of TNP and UI improvements have now been backported into FreeCAD proper; FreeCAD 0.22 also has a 'native' Assembly workbench so unless you have a lot of files making use of real thunders Assy4 Workbench, I think it's a good idea to switch earlier rather than later (-;

@dc42 Just to clear with the build as of 27th Mar, the version of the file using M3.8 directly does not seem to delay when you might expect it to. The version using M98 to run the same macro file does delay as expected.

I've just tried the same test files on a Duet3 running 3.5.0-rc.3+8 and see the same "odd" behaviour with the macro being "called" as a substitute for a gcode then the dwell does not happen when expected (they seem to happen at the end of the print), but with the same macro call using M98 then the dwell happens as expected.

These are the test files I used on the duet3, first the file I print (from my "jobs" directory):

G92 X0 Y0 M564 H0 ;(Home) ;G28 ;(Movement Configuration) G90 G21 ;(Park ppindle) ;(Move to center of table) G0 X150 ;(Start spindle) echo {"[L=" ^ line ^ " T=" ^ state.time ^ "] Running M3.8 #1" } M3.8 S24000 I1 ;M98 p"M3.8.g" S24000 I1 echo {"[L=" ^ line ^ " T=" ^ state.time ^ "] M3.8 Complete #1" } ;(Do some moves) G0 X100 G0 X0 G0 X200 G0 X100 G0 X40 ;(Change spindle speed) echo {"[L=" ^ line ^ " T=" ^ state.time ^ "] Running M3.8 #2" } M3.8 S12000 I2 ;M98 p"M3.8.g" S12000 I2 echo {"[L=" ^ line ^ " T=" ^ state.time ^ "] M3.8 Complete #2" } ;(Do some more moves) G0 X50 G0 X0 G0 X200 G0 X100 G0 X80 G0 X150 ;(Stop spindle) echo {"[L=" ^ line ^ " T=" ^ state.time ^ "] Running M3.8 #3" } M3.8 S0 I3 ;M98 p"M3.8.g" S0 I3 echo {"[L=" ^ line ^ " T=" ^ state.time ^ "] M3.8 Complete #3" } G0 X0 echo { "[L=" ^ line ^ " T=" ^ state.time ^ "] File complete" }

Then the M3.8 macro (that goes in system):

;if { !inputs[state.thisInput].active } ; M99 var dwellTime = 10 echo { "[L=" ^ line ^ " T=" ^ state.time ^ "] Waiting " ^ var.dwellTime ^ " seconds for spindle to change speed - #" ^ param.I } G4 S{var.dwellTime} echo { "[L=" ^ line ^ " T=" ^ state.time ^ "] Finished waiting for spindle to change speed - #" ^ param.I }

Note my Duet3 is a bench test system that only has a single stepper motor attached (as X) and has no homing switches hence the changes to allow the print file to run. I don't think any of these changes make any difference to the problem described here.

@NineMile you are correct, pausing during tool changes (or more generally, during macros) isn't supported.

@gloomyandy said in Position Verification Floor / Ceil inconsistencies.:

@NineMile I would also check that the machine that is showing the problem is actually running 3.5 rc3 (get a M122 output from it, unfortunately people sometimes get things wrong).

This was the first thing I asked for as I thought the issue was the machinePosition update delay on RC2 and below. It's definitely on RC3 and we're looking to test on more boards soon.

@NineMile its already a feature request https://github.com/Duet3D/RepRapFirmware/issues/761

T3P3 created this issue in Duet3D/RepRapFirmware open Report filename in error messages #761

@NineMile thanks, I've included this in 3.6.0-beta.1.

@dc42 I realise now I wasn't actually checking the tools array like that, I was checking a global vector storing additional tool details { vector(limits.tools, {radius, {deflection-x, deflection-y}}) } which is linked to the defined tool, so the existing fix should cover all of my usages. Thanks!

@dc42 said in Meta gcode result variable inconsistent with docs:

@NineMile I was about to start implementing this, but your implementation may save me some time. If your code changes are ready, please share them.

Did you test them in SBC mode, or standalone mode, or both?

@dc42 I submitted a PR with the changes here.

I've tested in standalone mode only, currently on an stm32h7 board but the PR cherry picks the changes onto the duet branch. I can test standalone on a Mini 5 plus if necessary but I don't have a viable setup to run SBC mode for testing right now.

@T3P3Tony I think it would be logical to add a fault state possibility to all the different subsystems, eg. tools, axes and to machine (or system) level, similar to heaters.

For example, if a tool change macro fails, that could trigger a fault state on the tool, raise a "toolchange-fault" event, and also change the current machine state to paused.
I think it would make sense to pass a "cause" to a pause (or any automatically called) macro and let the user decide what to execute depending on what caused the pause, eg. user-request, toolchange-fault, heater-fault, etc...

I think handling aborts in system-level macros could put the whole machine into a fault-state which in turn could further prevent running any other "doing" action, eg. tool change, move, home, etc. which would change any current (physical?) state.

There is something here that has to be thought out: allow executing "disable" commands in system-wide fault state, eg. turn off heater, spindle, motor, power, etc. So it is not that easy to just prevent any executive command to run.

I think resetting any fault could be done in a standardized way, just like how resetting a heater-fault works already with M562. Maybe it could be extended to be able to reset any sort of fault (selectively). Then the user could decide whether it wants an UI popup, or it recovers automatically from an event macro, or issues the command by hand, etc...

Just my thoughts...