Topics created by NineMile

@chrishamm said in DSF Failed to serialize code:

@NineMile I think the messages from M291 are too long, so DSF cannot send them to RRF. The maximum length of a G-code is 256 bytes, which is exceeded by your logic, and depending on the number of parameters it's a bit lower in SBC mode due to the way G-codes are transferred. If you reduce the message length, it should work again.

I'm going to change the error message in v3.6 to be more specfic.

Gotcha, thanks for the clarification. It has definitely been fun trying to fit the M291 dialog contents into 256 bytes so yes, some of these could be right up against the limit (I know I pushed some over by adding the J2 parameter on some dialogs while testing with v3.6.

I'll take another look at dialog lengths and see where these need to be sorted out.

Thanks again 👍

@NineMile Conditionals are not supported outside files. You should wrap it in a macro file and then invoke it using parameters.

@dc42 said in `move.rotation` not updated in Object Model browser:

PS - I have been wondering whether each workplace should have its own rotation angle and origin values, however I can't find any indication that any CNC machines support this.

My usage of rotation compensation has been to probe a work piece, set the workplace origin, calculate the center position and then rotate it around the centre to align the workpiece with the axes. This is to account for the stock not being held perfectly in alignment with the machine. Different workplaces can refer to different work pieces being machined at the same time or different orientations of the same workpiece that are machined in sequence.

In both of these cases, the rotation value is specific to the workplace so personally I do think activating it on a per workplace basis makes sense.

Right now I track the probed rotation value in a global indexed by workplace and there's a gcode called by the postprocessor after switching workplace that activates the rotation from the stored value.

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

@NineMile one option would be to program an Arduino Micro or similar to count pulses received from the Duet and output a 40ms pulse on every e.g. 10th pulse received.

@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

@dc42 Just wanted to confirm, someone on the RatRig discord has used M260.4 to communicate with a Huanyang HY02D223B which was one of those VFD's that looks like Modbus but implements its own command model.

We compiled control examples for daemon.g for the Shihlin SL3 VFD and the Huanyang HY02 on this gist if anyone is interested.

@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.

@audryhome said in MillenniumOS - A CNC "Operations System" for RRF 3.5+:

@NineMile I have seen this thread , did not find him again , however this was in a corner of my memory for a while.
I am refurbishing a Roland CAMM 3 trying to keep the control panel with 3 separate x y z jogs.

Will test happily your work as soon the old panel is connected to the Duet6HC through a custom made board I am working on.

Excellent - Feel free to message if you need help with configuration - depending on the machine configuration you might need some custom configuration to make sure the probing directions are correct. For what it's worth v0.5.0 won't be out for a while as it's a pretty big change to the existing codebase.

@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!

@NineMile thanks!

@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...