Simulation has become inaccurate?
-
Is there a known issue with simulation?
I'm getting a significant difference between simulated results and print time results despite starting the build process when the machine is at temperature.
To me this could indicate either an error in the simulation (DAA maybe?) or more significantly something is behaving abnormally in the print itself.
I will add config files, gcode, etc shortly.
Hardware: v0.6
Firmware: 1.24Simulated time: 49min 29sec.
Print time: >57min15 (still running) 92%. -
Final Build time 1hr4min.
Gcode attached, downloaded from Duet with simulation time result, along with M122, and config file.
-
I'll run a simulation on my other machine that is on an earlier version of firmware and not using DAA sometime over the weekend. Other factor that may be an issue is a large cumulative jump distance in the gcode.
I tk it from the lack of responses the Ethernet/wifi/Maestro/V3 boards are all scoring minimal pecentage difference between sim and print, or am I in a minority that make heavy use of the simulation?
-
Hiccups of 107 in your M122 may be a contributing factor. Does simulation account for hiccups?
-
@bot said in Simulation has become inaccurate?:
Hiccups of 107 in your M122 may be a contributing factor. Does simulation account for hiccups?
Simulation doesn't allow for hiccups, however each hiccup is only about 50us so 107 isn't significant.
Simulation does take account of DAA.
-
What are the hiccups indicating? Isn't it something todo with being late for a stepper move? What sort of values do I need to be concerned about and how do I fix them? I thought my speeds and accelerations were conservative?
Any tests I can do to help identify what's going screwy with either the print or simulation?
-
@DocTrucker said in Simulation has become inaccurate?:
I thought my speeds and accelerations were conservative?
I suspect it may have something to do with your Z axis.
M92 Z3200That's a fairly high steps per mm, and it looks like you're using 2 drivers for the Z? Perhaps the hiccups are from the homing portion where may be a large amount of Z movement.
M122 will reset the hiccup count, so you can run it multiple times after performing different actions to see if you can find a movement that triggers them.
Another common cause may be retractions that are very fast, but your E steps aren't super high.
107 is nothing though. Now if you had 10.7 million on the other hand.
-
Thanks for the pointed on the hiccups. I've reduced my maximum z axis speed to 150mm/min and dropped the probe speed from 80 to 50. Still getting 20 hiccups in homing, two repeats of x-axis levelling, and a four point grid bed probe.
Any pointers on what level should be safe to avoid hiccups?
I'm going to run two builds in parallel on two different machines to look into the simulation time issue further.
Edit: No hiccups on a Ormerod 2 with 8mm screws. This had 300mm/min. 300mm/min divided by 8 (1mm screw on the new machine) gives 37.5mm/min. I've not got that much patience! Trying 60mm/min. Got a feeling this may be hitting the minimum firmware limited speeds fort he axis.
Edit 2: Hiccups gone. When I've more time I will try to find the maximum speed I can drive Z without hiccupping. 60mm/min is safe, 150mm/min is not. That would suggest the v0.6 can't cope with with a 16kHz step rate?
-
Results are in. Same parts, different parameters, machines, and firmware. Not to scientific!
Machine 1:
Ormerod2 v0.6
Mods: 8mm screw, radial part cooling fan, revised y axis end plates.
DWC: 2.0.0-RC7
Firmware: 1.24Machine 2:
P3Steel v0.6 + DuetShield
Mods: Dual Z Axis, 1mm screw, 16t GT2 pulleys on X/Y axis.
DWC: 2.0.4
Firmware: 1.24I am getting hiccups on the first machine too:
"Hiccups: 197, FreeDm: 100, MinFreeDm: 63, MaxWait: 2389277msThe hiccup counter is still raising on the second machine:
"Hiccups: 87, FreeDm: 100, MinFreeDm: 64, MaxWait: 888938ms"Build times...
Machine 1:
Simulated: 1hr28
Actual: 1hr27Machine 2:
Simulated: 1hr9
Actual 1hr26So the questions now are:
- How to calculate a safe maximum speed for an axis based on the step rate limit of the duet v0.6.
- Measures to take to reduce the hiccup count.
- Why is my simulation so inaccurate on the second machine?
Files to follow.
-
Machine 1
0260.gcode
config.gcode
config-override.gcode
m122.txtMachine 2
0103.gcode
config.gcode
config-override.gcode
m122.txtI think the error has something to do with how the machines handle pressure advance or dynamic acceleration adjustment. I think the addition of the duet shield isn't likely to muddy the waters is it?
Hot end and bed temperatures were both within 1C at start of build.
-
I hate to say it but you're pushing the hardware to its limits. The newer firmware with all the new features has a price and the slower CPU of the 0.6 board can't afford it.
-
@Phaedrux I shouldn't be getting hiccups on the Ormerod though. More on that one than the P3. Can't find anything that says what the limits are.
That doesn't explain the simulation discrepancy either. At the moment I don't know if the problem is in the print or simulation.
I appreciate the Duet 2 is nicer and more capable. I have worked on a couple, both ethernet and wifi, with and without screen and Duex5. Still not convinced I've got the hardware as far as I can yet even for v0.6, and would rather wait until after the refresh on the duet 2 anyway.
-
Can't find anything that says what the limits are.
Limits for hiccups? I don't think there are any rules about it. In your case there are not many, so it's not likely to manifest as an issue. If there were millions you may see some issues such as not being able to hit top speed or the board locking up, or odd pauses.
That doesn't explain the simulation discrepancy either. At the moment I don't know if the problem is in the print or simulation.
Agreed. The only difference I can see from the info provided is the DWC version and the Duet shield. I'm not really up on my 0.6 hardware so I'm not much use there. Differing CPU usage between DWC versions might explain it?
I appreciate the Duet 2 is nicer and more capable. I have worked on a couple, both ethernet and wifi, with and without screen and Duex5. Still not convinced I've got the hardware as far as I can yet even for v0.6, and would rather wait until after the refresh on the duet 2 anyway.
Certainly it's still capable hardware.
-
@Phaedrux cheers, my post read back a little aggressive, that wasn't intended.
By limits I meant what step rate the duet v0.6 is capable of. On a quick glance the step rate limits quoted by dc42 were referring to the duet2.
-
@DocTrucker said in Simulation has become inaccurate?:
@Phaedrux cheers, my post read back a little aggressive, that wasn't intended.
By limits I meant what step rate the duet v0.6 is capable of. On a quick glance the step rate limits quoted by dc42 were referring to the duet2.
No aggression noted at all.
From what I gather the 0.6 board uses an older Atmel SAM CPU in the neighbourhood of 80Mhz, off the cuff I'd guess it's about half the step rate of the Duet 2, which is in the range of 130k to 160k. But that's just a total guess on my part. @dc42 would be the one to answer that one.
-
Looks like an 84MHz processor on Duet v0.6/0.8.5 and 120 on the Duet 2.
Based on this:
https://reprap.org/wiki/Step_rates
...the Duet 2 can handle 360kHz step rate on one stepper or 180 on 3. So being over cautious I assume each stepper driven reduces the capable step rate by a factor of 0.793. 5 Steppers therefore gives an obtainable steprate of 113kHz if on a duet 2.To convert that to a duet 0.6 I multiply by 84/120 which gives 79kHz.
I think that indicates that the 16kHz mentioned before should be fine and it is something else causing the Hiccups. Is there a list of common causes somewhere?
That lot aside I appreciate it is a minor count and unlikely to be a factor in the simulation issue, I just like to fix things that look potentially broken!
Edit: That 79kHz figure is lower than two other boards listed on the reprap wiki page with the same processor, so I assume that is a safe limit.
-
@dc42 as I originally suspected it has something to do with the DAA (dynamic acceleration adjustment).
Build Simulation Time Actual Time 0104.gcode 1hr 2min 1hr 10min 0104.gcode (without DAA) 1hr 11min 1hr 2min 0104.gcode
0104_no_DAA.gcode
config.g
config-override.gHardware: V0.6
Firmware: 1.24
DWC: 2.0.4Edit: The effects of DAA can be seen, and are as expected - less ghosting with.
-
Can anyone verify if the above behaviour/error is present in RepRapFirmware 2 &/or 3?
Perhaps not with my gcode but run builds back to back with and without DAA, or perhaps just say if the accuracy of simulation is poor when using DAA on these later firmwares?
It is bizzarre that the system calculated a longer build time with, rather than without DAA. My understanding is that without it would just run upto the highest permitted config file acceleration values.
