Posts made by NineMile

Hi @chrishamm

I had a user try to run the MillenniumOS config wizard yesterday on a new SBC setup of RRF 3.5.4 on a BTT Kraken board, and they received the following errors:

I've not seen this before on a standalone setup, and this may well be the first person to try using SBC mode with MillenniumOS as I personally don't have an SBC setup to test with.

We managed to narrow it down to MillenniumOS usage of html codes within the M291 dialog commands, the file being run to cause these errors is here: https://github.com/MillenniumMachines/MillenniumOS/blob/main/macro%2Fmovement%2FG8000.g

I'm aware that this is problematic if used on something not-a-browser but MillenniumOS was always designed with browser usage in mind, and has been using HTML styling in dialog boxes since very early in development to make some of the information clearer.

Do you think this is something that can be fixed? I assume special characters are limited for some reason but I have no context as to why that would be the case in DSF and not in standalone mode.

@Macgyver said in Trouble with a if statement decision tree using M291 K:

set var.secondary_head = input("Enter your choice (1-4): ")

Another thing that jumps out here is that input is a variable, not a function - with S4 when the message box returns, input is set to the index of the value you selected, so:

M291 R"Choose Print Head" S4 K{"GS","GHF","GUF","GHR"}
set var.secondary_head = { input }

would result in the secondary head being set to 1 if you clicked GHF

@chrishamm sorry for all the questions but maybe you know the answer to this one too:

I'm trying to do the following, which runs a Modbus discovery command on a set number of addresses. The idea is to loop within meta gcode, because if the M260.4 command is called directly by await this.sendCode() then the response variable is defined at top level and then exists for the lifetime of the HTTP gcode buffer.

// Use a RRF meta gcode loop, so we can use the same response variable for M260.4
                
                await this.sendCode(`
                    if { !exists(global.modbusResult) }
                        global modbusResult = { null }
                
                    set global.modbusResult = { vector(${this.maxAddressesPerDiscovery}, null) }
                
                    while { iterations < ${this.maxAddressesPerDiscovery} }
                        G4 P100
                        M260.4 P${this.selectedPort} A{${this.addressStart} + iterations} B{0x08,0x00,0x00,0xBE,0xEF} R5 V"modbusResponse"
                        set global.modbusResult[iterations] = { var.modbusResponse }
                `);
                
                const modbusResult = store.state.machine.model.global.get("modbusResult");
                

If I trigger the above code, I get an error that looks like the lines aren't formatted properly.

What's the correct way to send code like this with conditionals from DWC? Is there one? I think I've seen other plugins create a macro file temporarily and then execute it using M98 but that seems like a rather roundabout way to execute macro code directly.

@NineMile said in Macro return oddities:

So if I were to remove the echoed output from the macros (it's actually less important if I can load probing data directly into DWC) then it should work?

Update: This does work, if the macros don't output any information via echo {} then the UI waits correctly for the command to run. Thanks @chrishamm

@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 said in Modbus Spindle Control:

@audryhome @NineMile does anyone actually use M568 to control the spindle?

I do

I use it to vary the RPM set by M3 or M4 from daemon.g, to implement variable spindle speed. It adjusts the spindle RPM over a set period between a high and low point, to avoid potential resonance conditions between the tool and workpiece.

I would say M568 isn't an issue though - it could be overridden in the same manner as M3, M4 or M5.

This isn't as clear cut with Tool::Activate() and Tool::Standby() as it appears that they can be called outside of a GCodeBuffer context (see: MovementState::SelectTool / GCodes::SelectPrimaryTool)

@dc42 said in Modbus Spindle Control:

However, there is still a need to turn the spindle off and on during pause/resume. So perhaps it would be better to define one or more standard macros to control spindles and have them invoked by M3/4/5/568.

Yes, agree. I think named macros for start / stop / rpm would work well. I'd prefer spindle details to be passed by parameter rather than part of the macro filename though.

I'm currently working towards v0.5.0 of MillenniumOS, which brings some pretty big changes along with it.

I'm overhauling the probing system to more effectively account for probing surfaces that aren't aligned to the machine axes - this can help make G68 rotation compensation based off corner or rectangle block probes more accurate, due to the way that probe deflection changes when probing an unaligned surface. There's a video here covering it.

The above video also covers protected probe moves, which I have implemented as part of a new MillenniumOS-UI plugin to Duet Web Control. The idea of this plugin is to expose the functionality of the MillenniumOS macros in an easier to use fashion, allowing operators to drive the probing macros directly via the DWC web interface rather than using the current dialog-driven system. It also changes the layout of the machine information shown at the top of DWC so it's a little bit more CNC focused. Here's some images of the current probing design:

Select probe cycle

Configure chosen cycle

Jog to position (currently the same interface as on the dashboard)

Probe status once started

I've been working on the probing interface for a little bit, but only enabled it to run probing cycles last week - demoing it live at SMRRF for the first time with the new Milo V2.0 we had there - luckily no broken probes or major issues and got some great feedback as well.

There's also a couple of new features in the plugin, including a WCS Origins window on the right hand side that lets you type offsets into each WCS and tab between them - this is useful if you're not using a touch probe and just want to be able to set origins by hand.

This new code is relying on some features from RRF v3.6 so won't be released before then, but thought an update was warranted as people have already seen this system in the wild.

@audryhome I like this idea - however there's areas other than M3, M4 and M5 that can control the spindle currently. The ones I'm aware of are at least M568 (set tool parameters, which can control spindle speed if the tool is currently active), as well as Tool::Activate() and Tool::Standby() which are called internally during tool changes, M109 and it looks like via an LCD screen as well.

Not sure how well these areas fit into overriding the 'public facing' gcode commands

@chrishamm said in Macro return oddities:

@NineMile I suppose you're running your board in standalone mode? If yes, see this related issue: https://github.com/Duet3D/RepRapFirmware/issues/925 DWC cannot yet determine when a code has actually finished, so it assumes the last code has finished once it receives a new reply. In SBC mode, you should only get back a reply of the requested code as soon as it finishes, but not before.

Yep, running in standalone mode. I would've tried to run the same command via serial to see when it returned but I broke the USB port off my board last week so that's no longer an option

I'd guess because the macro being called is "composite", and the first sub macro prints output when it returns, that is deemed to be the called command completing.

So if I were to remove the echoed output from the macros (it's actually less important if I can load probing data directly into DWC) then it should work?

Again, not necessarily a DWC issue but I'm noticing it while writing a plugin for DWC.

I build up a command to run a custom macro, and then when the user clicks a button I submit the macro code to RRF using something like this:

async runProbe() {
    this.probing = true;
    await store.dispatch("machine/sendCode", this.getProbeCode());
    this.probing = false;
}

this.getProbeCode() returns a string that looks like this: G6520.1 Q0 N0 H10 I10 P5 T10 C5 O2 J297.827 K110.56 L-4.965 which is all the values required to run a given probe macro.

Now what I'm seeing is this.probing being set to false before the probing macro itself is finished. The probing macro runs other macros and then uses some of that information to print output.

It seems like as soon as the top level probing macro calls the first 'child' macro (which is what actually loops and runs the probes), the call to G6520.1 returns and this.probing is set to false.

My understanding is that we should be able to wait for G6520.1 to run completely before returning but oddly, this doesn't seem to be the case.

Is this behaviour expected? I'm running RRF 3.6.0-beta.2 (stm32) with matching DWC.

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

@NineMile have you tested this in stand alone mode with the latest build here:
https://www.dropbox.com/scl/fo/ga0jqwfksechhukg2uiz8/AOV3DR8z1C0UWczc8Rx25gE?rlkey=4saeh9luddndvxbhb0kdaqugr&dl=0

I've been using the stm32 beta.2 release which has been working great. While I have a Duet 5 for testing this isn't currently in any active setup of mine so I haven't tried specifically with those builds yet.

@gloomyandy said in Modbus Spindle Control:

@dc42 I had a quick look at the linuxCNC HAL code for the VFD that the user over on discord was using. That looks like it uses the same crc16 and seed as modbus but has a different payload. I get the impression from a quick scan of the linuxCNC stuff that this is fairly common, devices which claim to be "modbus" use the modbus signal timing. framing and crc but do not use the modbus register/coil model and associated commands. But I'm certainly no expert on this.

This is my understanding as well. Theres at least a couple quite common Chinese VFD's which advertise Modbus support but don't follow the modbus-rtu data format - the Huanyang one encountered on Discord seems to be the most common though.

For my own understanding of the RRF codebase, I spent a bit of time looking at how custom spindle control might be implemented using DoFileMacro.

It seems like adjusting spindle state and rpm would probably need to move to some type of reconciliation based system - where direct calls to spindle->SetRpm() and spindle->SetState() would store values that would then be applied later while spinning a GCodeBuffer.

Applying the settings could be simply setting pin output states for a standard spindle config, like what happens now, or calling DoFileMacro to execute a user-provided control system.

However - there's areas in the code where spindle control actions appear to be taken from outside any particular GCodeBuffer (Tool::Activate() for example, called from direct LCD requests). These would not map cleanly onto just switching into a spindle control state in the current GCodeBuffer where the request was made.

My initial thought was to use the Daemon buffer for all spindle control, but a long-running daemon macro could impact spindle control, and vice-versa.

Does it make sense to run the spindle control actions in their own GCodeBuffer instance and synchronise it with the other buffers?

For example - when File buffer calls M3 to start the spindle, we change the pending spindle settings, notify that the spindle needs to be reconciled and then don't allow the File channel to continue until the Spindle buffer reports the settings have been applied?

Any thoughts on this appreciated, or if I'm missing any prior art that might indicate a smarter way to do this?

I'm going to be at SMRRF in a couple weekends so I'd be happy to chat about this in person if you're going to be there (David / Andy)?

@gloomyandy said in Modbus Spindle Control:

So I think there might still be a case for having modbus specific read/write operations but I'd be tempted to try and make them more generic ones that simply read/write a bunch of bytes and apply the timing and crc to them, but leave the formatting and decoding of those bytes up to the user in the form of a script?

Looking at the Modbus gcodes again this evening (M260.1 and M261.1) and it occurs to me that if the user has the ability to send arbitrary data then there's no distinction between these 2 commands.

It seems like this lower-level "raw" behaviour could be achieved with a single gcode that takes raw bytes and expects a particular number of bytes in response, something like this:

; Purely hypothetical request that expects 3 data bytes returned from the 3 byte data request.
; var.modbusRaw would be a vector of bytes
M261.3 B3 D{10,12,14} V"modbusRaw"

The underlying implementation would send the station address and deal with CRC, but everything to do with the data would be up to the user.

@gloomyandy said in Modbus Spindle Control:

As I said above I'm not a big fan of using modbus for serious errors, personally I'd say you should be using some sort of trigger from a hardware fault signal for that. But even in this case I suspect that the reality is that a second (or possibly) more would be fast enough to handle that situation.

I agree with this to a point, but I'd take a guess that at the moment, the majority of spindles that are being run from RRF will be running without any feedback from the VFD at all - because just getting them connected up and running with direction control is complex enough, let alone working out how to get feedback inputs and writing RRF macros to process them properly.

The best thing about Modbus control is only needing to run 2 wires to the VFD, and getting 2-way communication with minimum complexity on the hardware side.

IMO It's much easier to write spindle control macros for a particular VFD type once that include some level of machine and vfd protection using Modbus feedback than it is to walk people through the hardware and VFD setup to implement hardware-based alarming and failure recovery. Especially with all the different types of VFDs out there that all seem to work slightly differently on the hardware side as well.

@gloomyandy said in Modbus Spindle Control:

I'm curious in the table above, it lists a "start" value, but I don't see any mention of that either in the spec I linked to or the code. Where is that table from?

I mentioned this briefly in the gcode I posted for the other style of control - this is from the VFD manual for the Shihlin SL3 which regardless of modbus-rtu spec, specifies a quiet time of 10ms between requests to give the VFD processor enough time to respond. If you send a request before this 10ms timer is up the request errors out.

Attaching the SL3 manual here because I think it's probably one of the most verbose VFD manuals I've come across that explains the Modbus control approach.

20220609_SL3_User_Manual_V1.03-041.pdf

@gloomyandy said in Modbus Spindle Control:

I don't think that is really the case. If you take a look at the modbus write funtion here: https://github.com/Duet3D/RepRapFirmware/blob/3.6-dev/src/Comms/AuxDevice.cpp#L190

Ah yep, good point on the timing concerns. So the user on Discord who has used the UART functions to implement the HY style "Modbus" comms might just be getting lucky with timing / silent durations that work for that particular VFD but with no guarantee of working on others.

@gloomyandy said in Modbus Spindle Control:

So I think there might still be a case for having modbus specific read/write operations but I'd be tempted to try and make them more generic ones that simply read/write a bunch of bytes and apply the timing and crc to them, but leave the formatting and decoding of those bytes up to the user in the form of a script?

I think there's definitely scope for this. I wanted to use the 0x08 Modbus function before to autoscan for devices on the bus, but this is not currently possible using the Modbus read / write functions as that function code is not implemented.

Reducing these functions to taking a station address and a data field (everything between address and check fields in the below image) would work well (ignore ASCII mode I wanted to include the headers).

@gloomyandy said in Modbus Spindle Control:

That's my take on this, I'd be interested to hear @dc42 take on the matter. To help with that, do you have any feel for how often spindle commands are actually issued and what sort of polling might be needed for status reporting? Can this status polling perhaps be optimised by for instance only doing some of it immediately after issuing a command?

I would say under normal circumstances, control commands would be executed on a similar cadence to tool changes. For each machining operation in a gcode file, you would usually stop the spindle, run a tool change, set the spindle RPM and then start the spindle.

In my particular use case, I also want to be able to monitor the output speed of the VFD on a regular basis so I can pause or abort the job if the VFD triggers an error - it would be quite important to do that quickly, but I think polling the VFD every half a second or so is enough.

From a control perspective, the worst case scenario I can think of right now is my implementation of variable spindle speed control - it actively changes the rpm of the spindle up and down constantly to avoid resonance frequencies, and right now that happens at the same rate as polling the VFD (every 500ms).

From a start / stop perspective, I think the worst case might be something like the rapidchange toolchanger, which starts and stops the spindle in both directions within a couple of seconds.

So I think at the absolute worst case we're looking at half a second between spindle control commands or status checks.

Edit: I don't think status checks can be optimised to only check after commands. Imagine if you start a spindle and then run a 10 min machining op, and 8 mins in the VFD overheats and shuts down. RRF wouldn't know about that and could potentially keep running the toolpath while the spindle is stopped, which would cause all sorts of issues including potential broken tools. I do think the status checking needs to be running at all times while a spindle is running.

@gloomyandy said in Modbus Spindle Control:

would hope that if there is a loss of communication you could raise an event. if there is some sort of safety issue here that needs a fast response I'm not sure that handling that via modbus is a very good solution. Don't these devices typically have some sort of "alarm" function/signal that can be hooked up to an input pin?

There's usually a configuration on the VFD side that can be used to trigger an alarm if there's been no communication in a particular amount of time, with additional configuration to control how the VFD responds to that. For example on my Shihlin SL3 I have it configured to alarm and stop if there's no comms from RRF in 2 seconds.

I think this could be done from the RRF side by tracking the last successful read from the VFD and either pausing or emergency stopping if it's been too long.

@gloomyandy said in Modbus Spindle Control:

An interesting question is that if we went this way should we keep the existing modbus gcode commands (that handle the various register/coil commands) or drop them and simply have a modbus read/write command that does the minimal framing (timing + <packet content> + crc) and leave it up to scripts to construct the "packet content"? At the moment we only support a subset of the modbus-rtu commands listed in this document: https://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf so the current implementation may need expanding?

If you discount CRC, the only real difference between the Modbus gcodes and the UART gcodes is that the Modbus ones restrict the functions that can be called. It might make more sense to add a CRC option to the UART commands and let the caller build the packet contents in whatever fashion they want rather than having commands specifically for modbus-rtu.

If we want to make it easier to build particular packet formats then maybe we could just add meta gcode functions instead (we could actually do that for CRC if we don't want to add an option to the UART command itself). Maybe just remove M260.1 and M261.1 entirely and move that functionality into meta gcode functions for packet building / parsing?

Actually the more I think about it the more I think you're right that macros are the right approach. It means people could implement entirely custom spindle control systems, and from the spindle control side it would just need an additional spindle type that calls system macro files if they exist

@gloomyandy said in Modbus Spindle Control:

@NineMile Would this work with the VFD discussed over on discord (the HY02D223B I think)?

Personally I'd prefer to extend RRF via external scripts to handle the various spindle operations. I don't think changes in speed or other spindle changes happen so often that doing this would be an issue. So basically have RRF call out to a script (with parameters if needed) for every spindle operation (start, stop, change in speed etc). I'd pair that with adding/extending the existing modbus read/write commands to offer a way to write just a set of bytes with modbus framing and crc. Looking at the LinuxCNC source it seems there are a number of VFDs (like the HY02D223B) which seem to use modbus like communication (including the "normal" modbus crc calculation), but which do not follow the register/coil model of modbus-rtu. So maybe having a way to read/write an arbitrary set of bytes with the required framing and crc would allow scripts to handle the protocol formatting? One advantage of this approach is that in theory you could use the same mechanism to talk to a VFD that does not use modbus style packets at all (though this would require any crc to be calculated by the script).

I like this approach as well, although Jay pointed out that using system macros or whatever would involve SD card reads for every spindle control action.

I did notice when reducing my daemon.g loop delay below about 500ms there were sometimes instances where the machine would halt for a short period between movements, which could be an issue with retrieving information from the VFD on a regular basis.

One of the benefits of integrating the reads at least into the main spinloop would be that we could fire events on a loss of communication.

You're right though, since the HY02D223B doesn't specifically support modbus-rtu then this would be an issue. It might be possible to solve that by allowing the "Modbus device" (bad name for this I know) to use either Modbus or raw UART, with the raw UART setting having options for unCRC'd, CRC16'd etc.

So I've been thinking about how spindle control could be integrated directly into RRF in a manner that wouldn't require a HAL to be written in C++ for each type of VFD, and the approach that seems to make sense thus far is to implement a modbus device type that can be assigned to an address on a configured aux port, and then assigned to a spindle of type modbus.

The modbus device type stores a limited number of read and write commands - reads are run on a configurable interval and populate data into the object model, one or more write commands can be configured to act as the actions to take to run a spindle forward, in reverse or to stop it. It would also be possible to run stored commands manually (think of like how M261.1 currently works but rather than specifying all the details you just pick the command number to run).

The nice thing about abstracting the modbus device out is that it could also work to monitor and manage non VFD devices using stored commands.

; Configure Aux 1 to Modbus / UART
M575 P1 B57600 S7

; Create Modbus device 2 at station 80 on Aux 1,
; waiting a minimum of 10ms between requests.
; Some modbus devices have defined processing
; delays between requests that should not be violated
M610 P1 I2 A80 D10

; Assign read commands to device 2. Maximum of 5?
; NOTE: Commands are all named, this is purely for
; readability purposes in the object model.

; Read 5, 16 bit registers from 0x1001 every 500ms.
; These values would be available in the object model.
; P0 is the command index that can be used later
; to refer to this command.
M611.1 I2 P0 S"spindleState" R4097 B5 D500

; Read 1, 16 bit register from 0x1003 every 250ms.
; Multiply the value by a factor of 60 to convert
; this to RPM
M611.1 I2 P1 S"spindleSpeed" R4099 B1 D250 F60

; Read 1, 16 bit register from 0x101B every 500ms.
M611.1 I2 P2 S"spindlePower" R4123 B1 D500

...

; Assign write commands to device 2. Maximum of 5?

; Reset
M611.2 I2 P0 S"reset" R4353 B38550

; Run Forward
M611.2 I2 P1 S"runForward" R4097 B2

; Run Reverse
M611.2 I2 P2 S"runReverse" R4097 B4

; Stop
M611.2 I2 P3 S"stop" R4097 B0

; Emergency Stop
M611.2 I2 P4 S"emergencyStop" R4097 B127

; Set RPM
; This command is special as it does not
; define a B-value - the B argument must
; be given if this command is run manually,
; and would be passed from the spindle control
; code.
; The F argument is a scale factor to adjust
; the input value into the right unit for the
; VFD, in this case from RPM to Hz.
M611.2 I2 P5 S"setRPM" R4098 F0.01667

; Create Spindle 0 as a Modbus spindle,
; using device 2.
M950 P0 T2 I2

; At this point the spindle will exist and RRF
; will start polling the Modbus device for each
; of the read registers defined. It will not
; be controllable because no write commands have
; been assigned to the spindle yet.

; F is the command number(s) to run in order
; to start the spindle. Assign write command
; 1 to start the spindle forwards.
; R is the command number(s) to run in order
; to run the spindle in reverse.
; S is the command number(s) to run in order
; to stop the spindle.
; V is the command number(s) to run in order
; to change the speed of the spindle
M611.3 P0 F1 R2 S3 V5

; For a device that need writes to multiple
; registers to start the spindle, you might
; implement them like the below

; Enable
M611.2 I2 P1 S"enableSpindle" R4097 B1

; Stop
M611.2 I2 P2 S"stop" R4097 B0

; Direction field is part of a bitmask,
; bit 1 set indicates run in reverse

; Forward
M611.2 I2 P3 S"setForward" R4098 B0

; Reverse
M611.2 I2 P4 S"setReverse" R4098 B1

; Configure spindle commands
; For forward, run forward and enable
; For reverse, run reverse and enable
; For stop, run stop etc
M611.3 P0 F3:1 R4:1 S2...

I realise this is somewhat complex from a configuration perspective but it means adding support for any modbus-rtu capable device should be doable in configuration only.

If anyone has any suggestions on this, whether it's too complex or whether there's a way to allow this to support non modbus compliant systems as well (e.g. HuanYang VFDs) then I'd love to hear it.

I'm willing to take a stab at implementing this approach if people think this is reasonable.

@dc42 said in &#x60;move.rotation&#x60; 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.

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