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:
M350 A1 I1 in config.g as it can only help... (Should I be interpolating or no???)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:
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:
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:
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:
sudo apt-get update,sudo apt-get upgrade (everything is at 3.5.1)debug in /opt/dsf/conf/config.jsontest_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.gtest_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.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
Hi All,
I've got a large format printer that uses gates G2 belts (10mm) with 30t pulley idlers. So far I have only been able to source this size of pulley from aliexpress as it is somewhat off from the normal 20t style. After several weeks of printing these pulleys start to make a crackling noise on rapid movements, and upon inspection I can observe degradation (sometimes to the point of ball bearings falling out upon disassembly) of the bearings on the idler.
I could get the 20mm variant from gates brand through filastruder and adjust my design to fit, but I thought it might be worth asking on here if anyone has a good source for high quality idlers.
Best,
T
@dc42 @T3P3Tony I'm wondering if this slipped past you.
I still haven't gotten into the testing phase but the info would be greatly appreciated.
Thanks,
T
Hey all,
I just received my first 23CL with brake, I'll begin testing it on my system soon (very pumped).
A couple questions for the Duet3D Team:
Are the board pinouts going to be released soon?
Were there any thoughts about I/O? It's hard to tell from looking at the board inside whether I could attach an endstop...
Are the functions of the brake abstracted or can they be configured like a normal brake setup? Specifically:
If the 23CL is the last board in the CAN chain, is there a way to set a termination resistor without making a patch on the cable coming out of the M8 connector?
Other boards with the RJ11 have a clear daisy-chain routing pattern, what is the recommended way to connect multiple 23CL on a large machine? I was thinking about using a tool distribution board?
Any updates on the nema17 version?
Thanks,
T
@gloomyandy MB6HC with 4x 1HCL and 1x 1LC, was on 3.4.6 before.
In some of my files I use G54 and G55 to move between two different working areas during the job (CNC). When using 3.5.0-rc.1 I noticed that I randomly get target position outside machine limits errors where previously these errors did not occur.
Upon inspection of the files I can see that the G1 commands that are sent are supposed to be in the G55 working space, so this error seems strange considering the commands are preceded by a G55 in the file. When copying this command into the console and running (after the job is cancelled by the error), I get the same machine limits error. If I send a G55 command, and then the "bad" line, it executes without any error.
My guess about the bug here is that there is a G54 command farther down in the file that is getting executed early, so I tried putting M400 and G4 S0.1 commands in front of these, but the issue persists.
Attached here are my config.g, override and a sample file which makes the error happen:
config.g.txt
config-override.g.txt
error_maker.nc.txt
The important thing to note in this sample file is that my machine has Y soft limits from -600 to 0, so a command like G0 Y20 will fail unless it is given in the G55 system.
I'm guessing this has something to do with motion planning and queueing, which I know there have been some changes to in 3.5.
Cheers,
T
@dc42 This did not fix the axis drop when sending m18 but it did seem to keep the axis from dropping upon hitting emergency stop.
I also noticed on this belt driven z with the 1HCL that sometimes the axis will drop during tuning using 3.5.0-beta4 (and still with beta4+ from dropbox). I believe I've fixed the issue by increasing the current slightly but if it worked in 3.4.5 with the lower current that would be the ideal situation. Can open a new thread for this if need be.
Overall the new firmware is making my X and Y 1HCL axes run super smooth/quiet and they seem to be able to run much faster than before.
Cheers,
T
Just upgraded from 3.4.5 --> 3.5.0-beta4 today to try the new PWM controlled brake feature on my machine. I use several 1HCLs on 48v and was previously running 48v and 24v to all of them for solenoids and a brake on the z axis (belt driven).
I used the command M569.7 P120.0 C"out0" V24 S250 to configure the brake and it all seems to work well until I tried M18 which made the Z axis drop. After M18 the axis is movable by hand with no resistance until resetting the machine.
@dc42 I'm assuming this is a bug as in 3.4.5 this did not happen with the 24v (non PWM) brake.
Cheers,
T
@dc42 Would it be possible to skip tuning or to perform mirrored tuning in this mode? I'm wondering as I have a rigid machine with a motor driving each side of the gantry.
Thanks