I just set up my duet 3 with a raspberry pi.
I am upgrading a cnc machine from duet 2 wifi to duet 3 and am wondering if I can use the workbee control on the pi so that I can see the machine/work coordinates. Or maybe just show the machine coordinates as well as work coordinates in the duet 3 web control.
Thanks,
T

@Phaedrux Just tried with RC2, no luck and jerks happen in the same places on same file.

Hello all,
I’ve got a cartesian machine running 5x 1HCL boards all running 3.4.5 stable. For while I was using the closed loop function on the boards, working great but noisy and high-speed feedrates were limited.
I noticed that on power up the machine can still generate driver-error events when axes are moved/crashed, before tuning is run. The machine operates much quieter and faster in open-loop mode, so I’m wondering if it’s possible to only use the encoders for position confirmation/stall detection. If so could anyone provide an ideal sequence of commands to enable this?
Thanks,
T

@MintyTrebor With the 3.3rc1 update globals are now displaying correctly in btncmd!
Would it be possible to have a color option for the Object Model panel?
Or a color switch based upon value like the z-probe status in DWC?
Also, what about a secondary organization structure in which buttons and panels could be grouped? Kind of like this on the DWC dashboard:

Just some suggestions, I'm really loving this plugin so far.
Much simpler than my previous node-red dashboard setup.
Thanks,
T

So a few days ago I implemented a dc42 ir sensor on a gantry machine designed to make paintings with duet 3. The idea was that the machine could probe a stationary reservoir of paint with the ir sensor, detect how much paint was remaining in the reservoir, and adjust brush dipping height. This worked extremely well until I started using black paint, which was not detected, and since the sensor triggers 2-3mm above the surface height, the machine dunked the ir sensor in black paint...
Wondering if anyone has a recommendation of a sensor or method of doing this reliably.
The reservoir is only 60mm in height. It would be nice to have +- 1mm accuracy.

One answer would be to use a longer range sensor like this adafruit time of flight :
https://www.adafruit.com/product/3316
This would allow me to limit the probing distance and never have the probe come near the paint,
but would require a little microcontroller to turn i2c into a probe signal (plugged into duet3 toolboard).

The issue with having a float based trigger (like in a toilet) is that paint builds up on it and changes the accuracy.

Anyone have other ideas? It would be great if the sensor I used had a digital output based on a 60mm trigger height. If we can read sensors on toolboards now is there an analog device that would work? Does anything like this exist that would detect acrylic paint and water?
Cheers,
T

This post is a continuation of what I believe to be this issue:
https://forum.duet3d.com/topic/19352/duet-3-3-2-beta2-sbc-jerking-motion

Issue:
I have a 5-axis machine with linear axes X,Y,Z and rotational axes A,B running rrf3.2 stable.
When sending a series of small segment, commands to the machine, a loud audible clunk happens intermittently.
The types of movements that create the clunks are simultaneous X,Y + A(rotational) moves.
Here is video:
https://youtu.be/egwhWUq8yAg
As you can see, it does not seem as if the machine loses steps, just starts/stops so quickly as to create a jolt.
Changing the M595 movement queue length (I have tried several values from 5 to 1000) only worsens this behavior to the point where steps are lost and even more clunks happen.

Here is my config.g:

;CNC Mode
M453
;Name
M550 P"tristan-painting-machine"
;Brake Pins
M950 P2 C"out8"
M950 P1 C"out7"
;Drivers
M569 P0.0 S0  I1
M569 P0.1 S0  I1
M569 P0.2 S1  I1
M569 P0.3 S0  I1
M569 P0.4 S0  I1
M569 P121.0 S1 I1
;Driver Mapping
M584 X0.3 Y0.1:0.2  Z0.0 S0 R0 P3
M584 A0.4  B121.0 S1 R1 P5
M584 U0.2 P5
;Current
M906 X2000 Y3750 Z2000 U3750 A1750 B1500 I100
;Microstepping
M350 X16 Y16 Z16 U16 A16 I1 
;Steps Per MM
M92 X80 Y80 Z80 U80 A46.1062140618 B26.6666
;Instantaneous Speed Change
M566 X500 Y500 Z500 U500 A500
;Max Speeds
M203 X13000 Y13000 Z13000 U6000 A40000 B40000
;Max Acceleration
M201 X750 Y750 Z500 U750 A2000 B2000
;Disable Idle Current Reduction
M84 S0    
M917 Y100
;Probe
M558 P9 C"!^121.io0.in" H200 F400 T2000 I1
;Limits
M208 X0 Y-1360 Z-145 A-72000 B-101.4 S1
M208 X1242 Y0 Z0 A72000 B230 S0
;Servos
M950 S3 C"io4.out"
M950 S4 C"io5.out"
;Endstops
M574 U1 S1 P"!io6.in"
M574 Y1 S1 P"!io1.in"
M574 X1 S1 P"!io8.in"
M574 Z1 S1 P"io7.in"
M574 A1 S1 P"io0.in"
;Head Endstop
M574 B1 S1 P"121.io2.in"
;Tool 0
M563 P0 S"Probe"
;Tool 1
M563 P1 S"1/4 Flat Brush"
;Tool 2
M563 P2 S"5/8 Flat Brush"
;Allow Movement
M564 S0 H0

M122 Report:

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.2 running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-956L2-G43S8-6J9D6-3S46R-KU2AD
Used output buffers: 1 of 40 (14 max)
=== RTOS ===
Static ram: 149788
Dynamic ram: 63020 of which 52 recycled
Never used RAM 145972, free system stack 132 words
Tasks: Linux(ready,83) HEAT(blocked,353) CanReceiv(blocked,881) CanSender(blocked,352) CanClock(blocked,352) TMC(blocked,19) MAIN(running,1265) IDLE(ready,19)
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:40:24 ago, cause: software
Last software reset at 2021-01-08 22:10, reason: User, none spinning, available RAM 145852, slot 1
Software reset code 0x0012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task Linu Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Aux1 errors 0,0,0
MCU temperature: min 42.5, current 43.8, max 44.2
Supply voltage: min 23.5, current 23.9, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.1, max 12.1, under voltage events: 0
Driver 0: position 54723, standstill, reads 54250, writes 55 timeouts 0, SG min/max 0/1023
Driver 1: position -56731, standstill, reads 54217, writes 88 timeouts 0, SG min/max 0/733
Driver 2: position -4137, standstill, reads 54214, writes 91 timeouts 0, SG min/max 0/837
Driver 3: position 4495, standstill, reads 54230, writes 75 timeouts 0, SG min/max 0/687
Driver 4: position -1200, standstill, reads 54226, writes 79 timeouts 0, SG min/max 0/294
Driver 5: position 0, standstill, reads 54295, writes 11 timeouts 0, SG min/max 0/0
Date/time: 2021-01-08 22:51:03
Slowest loop: 152.89ms; fastest: 0.03ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, maxWait 752461ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 630, completed moves 630, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 2, 11], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File* is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue* is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== CAN ===
Messages queued 80, send timeouts 0, received 50, lost 0, longest wait 1ms for reply type 6036, free buffers 48
=== SBC interface ===
State: 4, failed transfers: 0
Last transfer: 1ms ago
RX/TX seq numbers: 21479/21479
SPI underruns 0, overruns 0
Number of disconnects: 0, IAP RAM available 0x2c8a8
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.2.0
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 35.91
Maximum length of RX/TX data transfers: 3596/1696

M98 P"config.g" returns a green: M98 P"config.g" in the console.

Here also a file which produces many clunks (which is running in video):
wrenches_fake.gcode
It is hard to see which lines of the code cause the issue as I believe it is a problem with sending small segments.

I have had this issue since upgrading to the first of the 3.2 betas, but it does not occur 3.1.1.

Any thoughts?
T

@oliof I second this

@dc42 I can confirm that sending M595 P100 on the 3.3 beta firmware has resolved this issue.
Thanks

@gloomyandy yes sending G0 E100:200 works perfectly, extruding the specified amount on each extruder.

Is it possible to write the whole OM to a file on the sd card? Using duet3 + SBC 3.3rc1.
I was thinking maybe with execonmcode, but wondering if there is a native method.
My use case is a tool-changing machine with a docking switch, if docking fails I would like to save as much information on the machine state as possible before aborting/pausing the file.
Thanks,
T

Running 3.6 beta5+1 and the normal test_A_wrap_closed.g, test_A_nowrap_closed.g I got these results:

I'm now just trying to find a middle ground speed/acceleration combo where the missed steps do not occur, yet isn't prohibitively slow. @dc42 Any ideas on a semi-sealed, magnet-style closed loop motor? Maybe some existing product I could retrofit the duet3d encoder to?

Best,
T

Here are the results from the slow tests (speed and acceleration: M203 A8000 M201 A100) :

Very little variance, and if so a result of the measurement system/full stepping. So I'm guessing it is a problem with the high speed I'm using...? I'll keep bumping up the speed to try and find when the errors begin to occur.

@dc42 I need to run through-hole slip ring wiring, but I'm considering switching to the 5:1 ratio version of this reducer and maybe also a magnetic encoder. I'm only full stepping to see if it would help retain positional stability at these high speeds, and I'd like to have more accuracy if possible.

It seems like these kinds of motor do not give an absolute position read, the encoder type is listed as "magnetic incremental" and the pinout does not suggest SPI. I could potentially switch to the Duet3d magnetic encoder, but my reason for using these other motors/encoder is that I need a relatively sealed system, so I'd have to design a case with wire exits to go around it. I haven't found any sealed glue-magnet-style encoder motors in the 17 frame size, but maybe they exist?

I'm running 3.5.2 at the moment, would you suggest 3.6 and if so should I install 3.6.0-alpha.5+1 on the mainboard via bossa since I'm using an SBC?

Thanks,
T

Diving deeper into this and heeding your advice @dc42 @o_lampe. I've made several changes to how I'm testing:

1. Switched the A axis to full-step mode with M350 A1 I1 in config.g as it can only help... (Should I be interpolating or no???)
2. I'm using python3.11 on my RPI to generate the g-code, but I upped my general gcode output precision to four decimal points for the new "problematic macro" and the one that unwinds the axis.
3. Stopped using G1 H4 to avoid missed steps, instead I'm creeping up on the endstop with a set of loops like this (see a_to_endstop.g, x_to_endstop.g) for the full macros:

G91             ; Absolute positioning
; Small steps
while sensors.endstops[3].triggered == false
    G1 A-0.02 F500
    M400
G90             ; Relative Positioning

Interestingly I can hear the A axis clicking out the full steps when moving at this slow speed towards the endstop.
This should give accuracy to the nearest ~0.02 units which is good enough for me. Here are the results of my accuracy tests where I home initially and then run 25 measurement macros interspersed with a back-off command (test_method_accuracy_X.g, test_method_accuracy_A.g) :

Knowing that this new method is reliable, I ran some tests on the A axis with the "problematic macro" (
test_A_wrap_closed.g, test_A_nowrap_closed.g) :

I'm still observing the issue I had originally, although the full-stepping seems to have decreased the amount of error. The macro that unwraps still shows some annoying increase of 1-ish degree over 100 iterations (although it does seem to stabilize). @o_lampe I wonder if this hints toward your hypothesis of missed steps/pulses at high speed since there are increasing deviations for both macros? Still the macro with G92 is a big issue after 100 runs.

Here is the same set of tests on the X axis (test_X_wrap_closed.g, test_X_nowrap_closed.g) :

This is a completely acceptable deviation, and suggests to me that the issue has to do with my geared stage and the A motor moving so fast.

I'm in the middle of running the A tests again with limited speed and acceleration (although it is taking a very long time) and will update again as soon as I have the data.

Relevant files:
m122.txt
without_wrap_4f.g
with_wrap_4f.g
homex.g
homea.g
config (1).g

@dc42 I'm not sure if it makes a difference now that I'm using this discrete-creep-up method to test the accuracy, but both my A and X axes have their endstops connected to the same board as the motor/encoder.

Would it be beneficial for me to run these tests in open loop mode as well?

Cheers,
T

Hi All,
I'm running a PNP-style machine with MB6HC(SBC Pi5), 5x 1HCL. During continuous operation I noticed some drift in the A-axis. The drift was large enough that when commanding the (rotational) A axis to a 0 position (which looks square to the gantry after a homing cycle), it looks visibly off by about 10 or 15 degrees.

I was running some g-code which "unwraps" the A axis by calculating % 360 of the last position (I generate my code with python) and running a G92 A{remainder} to avoid a lengthy travel back to the normal range. I thought this might be causing the cumulative positional drift, and disabled it which seemed to fix the issue. But I was frustrated that what seemed like an obvious solution to the lengthy unwind wasn't working, so I ran some tests.

How I'm testing for deviation:

G91 
G53 G1 H4 A-360 F3000
G53 G1 A2
G53 G1 H4 A-4 F100
G90 
G4 S0.5 ; wait for motion to complete and allow OM to settle (nessecary? or maybe the issue?)
echo {"deviation from home position: "^move.axes[3].machinePosition + 142.5}
; 142.5 is the offset I specify in homea.g

The deviation tests involve running a homing-style motion but not setting any position, and then observing how far the current position is from the supposed home position by polling the OM. To me this seemed a viable method of recording the deviation, and I hope it does to everyone else as well. I've used similar tests in the past to verify the position of open loop systems during operation.

The two test files which simulate an identical set of motions that my machine currently makes during normal operation, one with the G92 unwrap and the other without:

• with_python_mod.g
• with_no_wrap.g

My testing script:

echo "homing the A axis to reset"
G28 A
echo "initial tolerance score"
M98 P"/macros/test_a_issues/print_deviation.g"

;default
M203 A25000	M201 A2000	

;slow 1
;M203 A10000 M201 A500

while iterations < 20
    echo "iteration ", iterations + 1
    ;M98 P"/macros/test_a_issues/with_python_mod.g"
    M98 P"/macros/test_a_issues/with_no_wrap.g"
    M98 P"/macros/test_a_issues/print_deviation.g"

This allowed me to observe the deviation over time as the problematic macro(s) were repeatedly run, and the results were quite worrisome. Graphing my console output csv from multiple runs produced this:

I tried the same motion macros with several different configurations, open loop mode, closed loop mode, assisted, slow accel and feedrate etc. Uncommented lines in my testing script and homing files should show how I produced the varying tests, and attached are my testing_x.g and print_deviation_x.g files that I used as a "control".

A axis runs the following hardware:

• 1HCL configured as shown in config.g and homea.g
• This Closed Loop Stepper
• This geared stage 1:10 ratio
• PM-R45 NPN Optical endstop on the output face of the stage

X axis uses a 1HCL, Nema23 motor and a 40T GT2 Pulley with 9mm Gates belt on a high quality linear rail.

The accumulation I observed with the G92 wrapping was apparent, but shockingly, its omission showed a serious drift moving in the opposite direction. This led me to think that this was a hardware issue, so I added tests with my simple belt driven (direct drive) X axis as a control. This showed a continual deviation increase of 0.5-1mm across the standard 20 iterations with the same file, despite the mode of operation.

So I have the following set of questions to ask on the forum:

• Is this a viable way to determine the deviation, and if not why? Do I need to give the object model more time to sync up before I make the comparison? If that is the case why are upward/downward trends visible?
• Is the issue related to the high speed at which I am running the A axis motor shaft, and why did a reduction of speed and acceleration not solve the cumulative error issue?
• Due to the 10x gear reduction of my A axis, could I be running into floating point errors for the shaft position/micro-step calculation? Maybe some tests with low micro stepping could answer this.
• On the X axis control, what other than a slipping belt pulley could cause the visible increase in X error.

Attached is my m122.txt M122 report after a single run of the with_python_mod.g macro. No blazing issues stand out to me from the report.

I'm happy to run additional tests and provide more information to diagnose the issue.

Cheers and hoping to figure this out,
T

@dc42 Hi, just wondering if you might have an update on timeline for nema 17 versions of the 23Cl?

Thanks,
Tristan

@dc42 On 3.5.2 I'm noticing some different behavior.
This time when the user presses pause while the move_x_macro.g is running, the x axis stops at X=300 and the machine enters a paused state. The macro does not seem to restart upon resuming.
The final line of the macro is G0 X400 which indicates the last movement command is being skipped? I tried adding a G0 X0 to the end of the macro and repeating with the pause, which made the machine stop at X=400. Repeating the G0 X0 did not help either.

EDIT:
I tried adding M400 or G4 P1 at the end of the file as workarounds for the last command issue, but this made the restart issue re-emerge.
Can provide logs again if need be.

Thanks,
T

@droftarts Thanks.
Is it possible to go back to 3.5.0-beta4 to temporarily avoid the issue while still having some of the 3.5 features?
I couldn't find it on the rrf/dsf apt package index.

Edit:
I built and installed rrf/dsf/dwc 3.5.0-beta4 but the issue persisted, so I had to stay at 3.4.6 to avoid the macros restarting.

I've been doing a bunch of experimentation on an SBC driven system with, sd jobs, macros, pause, resume, M400, and dsf-python.

I've encountered some issues and general unreliable results when triggering commands and macros from various code channels, especially when interacting with pause/resume during a file. So I preceded to try and create some minimal examples that showcase my issues. When trying to create a control example (without all the channel stuff) I came across this issue with macros.

Steps to replicate:

• Fresh 64 bit duetpi install on RPI4, sudo apt-get update,sudo apt-get upgrade (everything is at 3.5.1)
• Upload of my config.g
• Change LogLevel to debug in /opt/dsf/conf/config.json
• Reboot
• Home
• Upload of a gcode file test_custom_code_in_file.nc.g (added .g) for upload
• Upload of a macro move_x_macro.g
• Running of test_custom_code_in_file.nc produces expected effect, machine moves down in the Y axis, enters macro, moves over on X axis, finishes macro, and then continues to move down in Y. sudo journalctl --unit duetcontrolserver -f gives the following output during: normal_file_w_macro_nopause.log.g
• While running test_custom_code_in_file.nc, the user hits pause in dwc while the x axis is moving. The macro completes and the x axis moves out to a value of 400.
• User presses resume, and the macro is re-executed the X axis goes back to around 0, and repeats the motion out to 400. normal_file_w_macro_pause.log.g

As far as I know, unless the macro has an M98 R1 (which mine does not have) , the file should resume directly after the M98 call. I tried adding an M98 R0 command to the beginning, but got the same result.

For macros that toggle physical systems, i.e tool-change-like actions, a repeat like this can cause a crash.

My eventual goal here is to figure out how to pause a file without the fear of a macro being repeated.

Then I can move on to to diagnosing my other issues.
Thanks
T

Edit:
I tried going back to 3.4.6, and things functioned in the way I would expect. The macro did not restart after resuming.

I've got a SBC+MB6HC machine which I'm sending commands to via the POST /machine/code http request. Everything is running 3.5.1 stable.

My config.g has a M564 S1 H1 in it to keep the axes from being moved until homing is complete.
This means that if I send a command like G0 X436.5 Y-105.3 Z5 from the console or an http request, I get the correct error back: Error: G0: insufficient axes homed.
However, when I have a macro /macros/test_limit_macro.g with G0 X436.5 Y-105.3 Z5 as the contents, running M98 P"/macros/test_limit_macro.g" in the console returns the red error line plus a green bar as if the command completed successfully. In addition, running M98 P"/macros/test_limit_macro.g" via http returns an empty string result as if the command completed successfully.

Is this intended? If so it makes it hard to raise a meaningful error in the program that is making the http requests.

If its not a bug, are there any workarounds or alternatives to be able to extract the error output when running a macro via http request?

Cheers,
T

I've used DSF-Python to create some custom-m-codes that have dynamic function (checking entries in a database and executing different movements based on them). This has been working well, except I've crashed the machine several times due to hitting pause/resume when the macros are in a larger gcode file. It's unclear at what point the machine is pausing, and often some moves (like a necessary clearance) are skipped during resume.
I've been using this code to run movements from within the InterceptConnection loop:
cmd_conn.perform_simple_code(cmds, channel=CodeChannel.File)
Sometimes cmds is a single command, and sometimes a few commands separated by newline.
I'm also using this code to run macros:
(perform_simple_code('M98 P"/macros/test.g"', channel=CodeChannel.File)
The issue i'm experiencing with pauses might be coming from any of these three ways to execute codes, so I'm thinking it would be best to compartmentalize each set of commands into a dynamically written macro. Then I could implement the normal macro M98 R1/0 to achieve predictable pausing results. I'm wondering if this is the ideal way to go about this, or if anyone has any better ideas.

This brings me to my second question of writing macro files dynamically. I get a lot of errors when trying to write files in the /opt/dsf/sd/macros/ folder. In the past I made some chmod changes which allowed me to read/write in those folders, but it filled DWC with red errors about incorrect permissions. I'm on a fresh install now and would rather not do that again.

I could make some post requests to upload/delete a macro but it seems simpler to just write the files with python if I can get the permissions right. What would be the recommended way of freeing up the permissions of those files and folders? Would it be best to create a DSF plugin instead?

Thanks,
T