Hi! I have a feature request.

I would love if spindles could be defined that output a RC servo signal instead of a 0-100% duty cycle PWM. I'm using a brushless motor as a spindle, and I'm sure you've seen on the internet that I am not alone in doing so. Right now I'm controlling it using the M280 command, but this does not translate from RPM and is not compatible with any standard post-processor for CAM softwares. Also: Servos can not be defined as tools, which has implications when trying to implement a toolchanger which I plan to do.

For syntax, I suggest M950 C"pin" Rnn S Laaa:bbb

Where a naked S without a value indicates that the spindle should use a servo signal. Admittedly this in inconsistent with the current definition of M950 which does not allow having S and R in the same line, but perhaps that is acceptable. If possible it would also make sense for aaa and bbb to allow negative values, to intuitively define counter-clockwise rotation. Adding the Q parameter to this line should probably produce an error, unless the current servo implementation supports different frequencies?

Expected behavior:

M950 C"outputpin" R1 S L-10000:10000 

should define spindle1 using servo signal on outputpin with max rpm 10000 in both directions.

M563 P1 R1 

should define this spindle as as tool 1.

M5

should set active spindle to 0 rpm as interpolated between aaa and bbb (in this example outputpin to 1,5 ms pulse length). But not define rpm to 0 as interpreted by M3 or M4. Issuing an M3 or M4 without the S parameter after having issued an M5 should make the spindle resume last used RPM. I'm not entirely sure what the G-code standards say about toolchanges in this context, if the tool has changed (and/or the active spindle has changed), should the new tool/spindle inherit the last used RPM? I think it should, if you want another speed you should actively command this by including the S-parameter.

M3 S"5000"

should make outputpin generate 1,75 ms pulse length

M4 S"5000"

should make outputpin generate 1,25 ms pulse length

It may be wise to have the M950 command always initiate the output to 0 rpm upon define, to make sure that a connected ESC if powered intiatites properly and does not move. Alternatively it could be a recommendation in the G-code manual to always issue an M5 command directly after the define, but this would imply the M5 should have an additional argument to allow disabling any of the defined spindles, if there are more than one.

This may not be a high priority feature, but on the other hand since the duet can already output this type of signal I'm hoping that it's so easy to implement that it can be added pretty quickly. It would help me a lot, and I'm sure I won't be the only one to use this feature in the future.

This could also be achieved by more powerful parameters for the rpm, although it would be less user friendly. For an example, you could expand the L parameter to Laaa:AAA:bbb:BBB where aaa=minimum PRM, AAA is minimum duty cycle, bbb is max RPM, and BBB is the maximum duty cycle. If aaa and bbb also accepts negative values this would allow any type range of pwm to be defined, including 0-10v or 0-5v VFDs or industrial servo drives where 0 rpm is somewhere in the middle and they can rotate both ways. But it is important in all these cases that the M5 command outputs 0 rpm and not 0 pwm (plus pulling spindle enable pin low, if defined).

@Phaedrux I have not, since everything else works it seems unlikely that this would be the problem. But if nothing else solves this problem I can certainly try other power supplies and see if my 48V supply causes interference.

@dc42 It sounds like I should try removing the voltage divider then to see it that helps. I built my pendant february 2022, when comparing to github this seems to be the latest firmware for the pendant.
The firmware of the mainboard has changed. Previously I had 3.4.5 and now I have version 3.5.4.

Looking at the change log the only changes that mention serial port is the following line:
"[Duet 3 MB6HC] [Duet 3 Mini] A PanelDue or other device using the same protocol attached to the second serial port did not work"
So there is another serial port? If I get desperate, how do I configure this port and where is the connector? (Edit: It's on IO_1, yes? Finally found it in the docs. Same config-code just IO_1 instead of IO_0 I guess)

Looking at the hardware revision I see that a separate connector has been added for paneldue. So I gather there is a slight chance that this has affected the performance of the serial interface, with more/longer traces being added. I still connect to the old IO_0 port. It gives me some hope that simply removing the voltage divider could solve the problem. And also that there is another connector I can try, in the unlikely event that the circuit board connector or the traces are the problem.

I'm sorry for asking so many questions before trying what has already been suggested. My machine is quite far from where I live so I don't have access to it every day. When I do have access I want to understand which options I have so I have a good change of solving the problem.

Hi! Yesterday I replaced my 6HC motherboard because I wanted the higher voltage of the 1.02 revision (I had 1.01A hardware before). I simply transferred all the config files and plugged the new board in, while also replacing the power supply (48v instead of 24v).

Almost everything worked perfectly right away, but for some reason the CNC jog pendant is now completely unusable. Only one in maybe 20 "clicks" on the joq wheel actually triggers motion, but since it does sometimes trigger motion I can also conclude that it partly works (when it does move the direction and step size is correct). It's as if the serial port has bad connection, but I've checked and double checked the connectors and cables and I can find nothing wrong. It also worked perfectly before changing the board so I'm not expecting to find any hardware faults in the pendant or the wiring. If it was a bad connection I would also expect the behavior to change if I wiggle the cable and connectors while rotating the jog wheel, but I can find no such correlation.

The pendant is the one described here: [https://docs.duet3d.com/User_manual/Connecting_hardware/IO_CNC_Pendant](link url)

Has anything change regarding the serial interface from 1.01a to the current board? Has the 5V pin on the port been been downgraded such that it can no longer feed the microcontroller in the pendant? Or has there been a software update that could affect the serial communication?

I desperately need this to work so I'm seeking advice on where to start looking for a solution. Is there another serial port I could use for testing purposes? (I am currently using IO_0 as described in the pendant-docs). Should I try replacing the resistors of level-changing voltage divider in the pendant to lower values so they drive the data line harder? Does it truly need the voltage divider or would a 5V serial signal work? Grateful for any guidance I can get!

@dc42 thanks, exactly what I needed to know! I'll be staying within safe operating limits. Given this information I probably won't push much past 48V.

Hi! I just recently bought a 6HC mainboard v1.02b, as an upgrade for my machine that currently uses an older v1.01 board. I'm doing this so I can increase voltage and thus stepper motor performance.

But before I install it there is one important question I would like the answer to. This board is officially rated up to 48V, but is that the absolute max voltage or the highest recommended nominal voltage? If 48V is absolute max I would hesitate to run it off a 48V power supply without turning it down a few volts. But since I'm doing this upgrade to get maximum performance I don't want to tune it down just because I'm not sure.

So yeah, will it run safely from a 48V power supply or should I turn it down maybe 45V?

Thanks in advance,

/David

@dc42

Any progress on measuring and publishing new step rates for the 1XD? I've been regularly checking the 1XD docs, the "Duet maximum achievable step rates" post, and the google docs spreadsheet in said post but I have not seen any updated figures as of yet.

@dc42

Thanks for the answers! I was leaning towards the JMC integrated servos rather than clearpath, these are about half the price and accept a maximum steprate of 200khz. Although clearpath is also an option I was considering, but using them would be the no-compromise route so then I would lean even more towards 6xd.

Either way I'm mostly limited in the time I can spend putting together new hardware, and going 1xd is a quicker fix. Like I said I just need to understand what performance I can expect so it doesnt end in dissappointment. If new measurement are posted in a week or two I'll wait for them to decide. Input shaping is not a dealbreaker for me since I have a very rigid machine.

Again big thanks!

Hi. I'm looking to get some insight in what performance limitations I may get when daisy-chaining four 1xd boards compared to using a 6XD board.

First: I believe the documentation on the 1XD boards i a bit outdated. The maximum step rates seem to be measurements on firmware version 3.2, but reading the step rate post in this forum and the firmware changelog it seems this was improved in version 3.3 (new rates not measured?). This may also have changed again due to input shaping? Anyone have a clue on what step rates I could expect today, using 4 boards on the CAN bus?

Also regarding input shaping the documentation has conflicting information, one place is saying that it will not be implemented and therefore 1XD boards should not be used to drive primary axis, and one place saying that it will be implemented. Looking at the firmware changelog it seems like it is already implemented? What is the actual status on this? And if I choose not to configure input shaping, does that improve step rates?

So the documentation on the 1XD needs some updating. But let me get to my actual core questions.
First: Is the 1XD a viable option for the main axis of a high performance machine, if I can accept step rates of (worst case) around 40kHz? The documentation says no but again that seems to be based on outdated information.
Second: The 6xd uses single ended signaling and not differential. If I want to combine this with integrated servos (driver mounted on the motor) Could I reliably send step-dir signals up to 200kHz over 4 meter long cables in parallel with power-feed cables? I could see this being a problem but electronics is not my field.
Third: are there other potential issues besides the step-rate and signaling to consider? I don't know how motion control is implemented on external boards, does axis synchronisation suffer due to latency in the CAN bus or is there some smart scheduling being done with synchronised clocks?

The background: I have a CNC router currently driven by the 6mbhc. Ball screws 10mm pitch for x and y, 4mm pitch for Z. Double Y axis motors (så 4 motors in total). I use this CNC for production and I want more speed, power and reliability than I can get out of open loop steppers. Ideally I would like to go all in and add 3000rpm servos on all axis and turn the rapid feed and acceleration up so high that I'd need to bolt the machine to the floor. Cycle-time is money! To get the very best performance clearly the 6xd is the way to go. But I have limited to time spend on this conversion, and going this route would mean building an entirely new control box and redoing all the wiring before I can even start configuring the new system. Then I need to so servo tuning after that. I'm also concerned about signal integrity this way. I was planning to use integrated servos with the driver mounted on the motor, meaning the step-direction signals may need to be routed up to 4 meters in parallel with power feed cables for the other motors and the spindle. On the 6xd these signals are single-ended and not differential. I could see this being a problem if I have pulse rates up to 200kHz, but I am no expert on electronics.

The other option is adding 1xd boards to my 6hc motherboard. Given the limited step rates of 1xd servos would make no sense, so I would go with closed loop steppers. This will not improve feeds by much but it should improve acceleration and reliability. You answers will help me decide if I should settle for this option.

Thanks in advance. And sorry for the long post, part of it is because the documentation is a bit contradicting.

@Phaedrux

The board is more than a year old so no warranty, but regardless I went for the SBC route to just get it running. I realized version 3.3 actually uses the same SD card for SBC and standalone, and the first SD card I used was out of date. I can now connect via the SBC and the versions are matching for sure (all 3.3), so for a while I was relieved and thought I could start production again. But despite being the same version as I used last week my jobs and macros are partially broken, the code is interpreted differently.

I have macros that repeat the same job in a pattern to produce multiple parts efficiently. If I run them as a macro they will terminate after just 2 out of 25 instances the first time I run it with no error being reported. If I run the same macro again it completes the whole pattern, but the first two parts have now been run twice and may need to be scrapped. It's also a wast of time.
If I run the exact same file from the job folder it finishes 5 instances out of 25 and then will not run again because it does not clear the loop variables so they can not be reassigned.

Also all my laser jobs (I have both a milling spindle and a laser mounted) now turns on the laser on the first G0 transport of each job, leaving a long straight line across the workpiece ruining it. Subsequent G0 moves are interpreted correctly.

Plus a bunch of other less critical issues...

I know, I know, the only thing to do is to upgrade to the latest version and hope that this resolves the issues. But I really just want this to run and I don't have the time to spend on it right now and I know syntax has changed for some M-codes in config and homing macros so it won't be a quick fix. I could not imagine that the jobs and macros would be broken just by running SBC mode...

Since I'm desperate to get this working I now tried connecting it via ribbon cable and a raspberry pi 3B v1.2. I had an old SD card with the raspberry pi image on it and the raspberry pi boots up and connects to ethernet. But it does not load a DWC, and when running lsusb it does not seem to find the duet. I will admit that I'm not 100% if the Pi image and the duet have the same version number, but I'm sure they are close (possibly the Pi is 3.2.2 while duet is 3.3. Is there a way to check Pi firmware version?).

I have the duet powering the RasPi via jumper settings. It's a 3B pi with nothing else connected to it and both the duet and the Pi seem to run fine, except not communicating.

I'd still prefer having it working in standalone mode but if this is easier to fix I'll settle for that, so long as I get it running again quickly.

Results of journalctl -u duetcontrolserver -e

Apr 19 16:18:53 duet3 systemd[1]: duetcontrolserver.service: Succeeded.
Apr 19 16:18:58 duet3 systemd[1]: duetcontrolserver.service: Service RestartSec=5s expired, scheduling restart.
Apr 19 16:18:58 duet3 systemd[1]: duetcontrolserver.service: Scheduled restart job, restart counter is at 49.
Apr 19 16:18:58 duet3 systemd[1]: Stopped Duet Control Server.
Apr 19 16:18:58 duet3 systemd[1]: Started Duet Control Server.
Apr 19 16:18:58 duet3 DuetControlServer[2005]: Duet Control Server v1.1.0.5
Apr 19 16:18:58 duet3 DuetControlServer[2005]: Written by Christian Hammacher for Duet3D
Apr 19 16:18:58 duet3 DuetControlServer[2005]: Licensed under the terms of the GNU Public License Version 3
Apr 19 16:18:58 duet3 DuetControlServer[2005]: Loading settings... Done!
Apr 19 16:18:59 duet3 DuetControlServer[2005]: Initialising variables... Done!
Apr 19 16:18:59 duet3 DuetControlServer[2005]: Connecting to RepRapFirmware... Error: Duet is not available
Apr 19 16:18:59 duet3 systemd[1]: duetcontrolserver.service: Succeeded.
Apr 19 16:19:04 duet3 systemd[1]: duetcontrolserver.service: Service RestartSec=5s expired, scheduling restart.
Apr 19 16:19:04 duet3 systemd[1]: duetcontrolserver.service: Scheduled restart job, restart counter is at 50.
Apr 19 16:19:04 duet3 systemd[1]: Stopped Duet Control Server.
Apr 19 16:19:04 duet3 systemd[1]: Started Duet Control Server.
Apr 19 16:19:05 duet3 DuetControlServer[2019]: Duet Control Server v1.1.0.5
Apr 19 16:19:05 duet3 DuetControlServer[2019]: Written by Christian Hammacher for Duet3D
Apr 19 16:19:05 duet3 DuetControlServer[2019]: Licensed under the terms of the GNU Public License Version 3
Apr 19 16:19:05 duet3 DuetControlServer[2019]: Loading settings... Done!
Apr 19 16:19:05 duet3 DuetControlServer[2019]: Initialising variables... Done!
Apr 19 16:19:06 duet3 DuetControlServer[2019]: Connecting to RepRapFirmware... Error: Duet is not available
Apr 19 16:19:06 duet3 systemd[1]: duetcontrolserver.service: Succeeded.

Results of M122:

[17:15:19:033] === Diagnostics ===␊
[17:15:19:033] RepRapFirmware for Duet 3 MB6HC version 3.3 (2021-06-15 21:45:47) running on Duet 3 MB6HC v1.01 or later (SBC mode)␊
[17:15:19:033] Board ID: 08DJM-956BA-NA3TN-6J9F0-3SJ6R-1V86U␊
[17:15:19:033] Used output buffers: 1 of 40 (1 max)␊
[17:15:19:033] === RTOS ===␊
[17:15:19:033] Static ram: 150904␊
[17:15:19:033] Dynamic ram: 59980 of which 0 recycled␊
[17:15:19:036] Never used RAM 143308, free system stack 190 words␊
[17:15:19:036] Tasks: SBC(ready,4.1%,606) HEAT(delaying,0.0%,405) Move(notifyWait,0.0%,352) CanReceiv(notifyWait,0.0%,944) CanSender(notifyWait,0.0%,374) CanClock(delaying,0.0%,339) TMC(notifyWait,7.0%,93) MAIN(running,88.8%,1244) IDLE(ready,0.1%,29), total 100.0%␊
[17:15:19:036] Owned mutexes: USB(MAIN)␊
[17:15:19:036] === Platform ===␊
[17:15:19:036] Last reset 00:01:56 ago, cause: power up␊
[17:15:19:036] Last software reset at 2023-04-06 19:09, reason: User, GCodes spinning, available RAM 107800, slot 1␊
[17:15:19:036] Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a␊
[17:15:19:036] Error status: 0x00␊
[17:15:19:036] Step timer max interval 14997␊
[17:15:19:036] MCU temperature: min 31.8, current 42.4, max 42.4␊
[17:15:19:036] Supply voltage: min 28.9, current 28.9, max 28.9, under voltage events: 0, over voltage events: 0, power good: yes␊
[17:15:19:036] 12V rail voltage: min 12.1, current 12.2, max 12.3, under voltage events: 0␊
[17:15:19:036] Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0␊
[17:15:19:036] Driver 0: position 0, standstill, reads 63092, writes 11 timeouts 0, SG min/max 0/0␊
[17:15:19:036] Driver 1: position 0, standstill, reads 63092, writes 11 timeouts 0, SG min/max 0/0␊
[17:15:19:036] Driver 2: position 0, standstill, reads 63092, writes 11 timeouts 0, SG min/max 0/0␊
[17:15:19:036] Driver 3: position 0, standstill, reads 63092, writes 11 timeouts 0, SG min/max 0/0␊
[17:15:19:036] Driver 4: position 0, standstill, reads 63092, writes 11 timeouts 0, SG min/max 0/0␊
[17:15:19:036] Driver 5: position 0, standstill, reads 63092, writes 11 timeouts 0, SG min/max 0/0␊
[17:15:19:036] Date/time: 1970-01-01 00:00:00␊
[17:15:19:036] Slowest loop: 0.12ms; fastest: 0.00ms␊
[17:15:19:036] === Storage ===␊
[17:15:19:036] Free file entries: 10␊
[17:15:19:036] SD card 0 not detected, interface speed: 37.5MBytes/sec␊
[17:15:19:036] SD card longest read time 0.0ms, write time 0.0ms, max retries 0␊
[17:15:19:036] === Move ===␊
[17:15:19:036] DMs created 125, maxWait 0ms, bed compensation in use: none, comp offset 0.000␊
[17:15:19:036] === MainDDARing ===␊
[17:15:19:036] Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1␊
[17:15:19:036] === AuxDDARing ===␊
[17:15:19:036] Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1␊
[17:15:19:036] === Heat ===␊
[17:15:19:036] Bed heaters = -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1␊
[17:15:19:036] === GCodes ===␊
[17:15:19:036] Segments left: 0␊
[17:15:19:036] Movement lock held by null␊
[17:15:19:036] HTTP is idle in state(s) 0␊
[17:15:19:036] Telnet is idle in state(s) 0␊
[17:15:19:036] File is idle in state(s) 0␊
[17:15:19:036] USB is ready with "M122" in state(s) 0␊
[17:15:19:036] Aux is idle in state(s) 0␊
[17:15:19:036] Trigger is idle in state(s) 0␊
[17:15:19:036] Queue is idle in state(s) 0␊
[17:15:19:036] LCD is idle in state(s) 0␊
[17:15:19:036] SBC is idle in state(s) 0␊
[17:15:19:036] Daemon is idle in state(s) 0␊
[17:15:19:036] Aux2 is idle in state(s) 0␊
[17:15:19:036] Autopause is idle in state(s) 0␊
[17:15:19:036] Code queue is empty.␊
[17:15:19:036] === CAN ===␊
[17:15:19:036] Messages queued 583, received 0, lost 0, longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 49 (min 49), ts 583/0/0␊
[17:15:19:036] Tx timeouts 0,0,582,0,0,0 last cancelled message type 30 dest 127␊
[17:15:19:036] ␊
[17:15:19:036] === SBC interface ===␊
[17:15:19:036] State: 0, failed transfers: 1, checksum errors: 3␊
[17:15:19:036] Last transfer: 99003ms ago␊
[17:15:19:036] RX/TX seq numbers: 1/1␊
[17:15:19:036] SPI underruns 0, overruns 0␊
[17:15:19:036] Disconnects: 0, timeouts: 0, IAP RAM available 0x2c83c␊
[17:15:19:036] Buffer RX/TX: 0/0-0␊
[17:15:19:036] ok␊

@Phaedrux

I did not, but I've tried two different internet routers, connecting from two different computers, with two different ethernet cables. All of which have been verified independently to be working. So i figured it would be unlikely to make a difference. I can still try if you think it makes sense, but I'm thinking there should be other things more relevant to try. Like reflashing the firmware? Can i place the install files in the sys folder on the SD card and trigger the install via USB? Or do I need to use Bossa for this if I cant access the DWC? And can I upload the same version or would it refuse because it is not an upgrade?

Either way I'm pretty desperate to get this working within a few days, I'm using the CNC for production in my startup. The last option would be to try using an SBC setup, but this takes some work and brings me no benefit so I hope it can be avoided. Very grateful for any help I get.