Just replying to myself with some difficulties with the above approach after thinking about it some more.

Sending a move and expecting it to take exactly the expected time slice. Unless you mirror exactly how the Duet is calculating velocities etc (not to mention latency of processing the move), then the time will be off. This delta t error is then cumulative which is why it becomes an issue. Reading back the M400 to know it is complete and then proceeding is better, but you then introduce an additional latency of read M400, compute target, send position.

It is pretty desirable to keep the Duet respecting acceleration and jerk limits, but you need at least 3 moves going at all times, let's call them A, B, C.

Move A is executing, B is next in the queue, and C does not exist We compute the target destination using data available right now (while A is executing) and send it as move C. This must complete before B begins executing Duet receives move C, adds it to the queue, and adjusts the speeds of move B Move A finishes and B begins Repeat

This could get shortened down to 2 moves A and B if the Duet could modify an in-progress move (before some deadline) once B got added. But that seems super complex.

The downside is that we have to compute move C with information at the moment while A is executing, but things will change while B is executing.

Some difficulties in doing the above are:

knowing the true machine position at the time we compute move C. The duet will be somewhere between A's start position and A's end position but we ideally would know exactly where knowing where the Duet is actually in the queue currently, ie. we think A is still executing but is it now executing B because our time estimate was off? (as in the first difficulty mentioned). Its almost like we want a sync pulse to be sent whenever we start a new move (and would be extra nice to have the Duet send the move duration whenever it starts a move

@sinned6915 thanks very much this is helpful

@jens55 said in CAN port question:

OK, I think I got the tool board thing figured out. When you leave the jumpers on the tool distribution board as if the particular port wasn't used and if you then connect a single pair of wires from the tool distribution board to the tool board, you in effect put in a stub that isn't in the daisy chain.

Correct.

Is the 300 mm stub length limit the limit of a single stub or all stubs added together?

It's per stub. There is also a total limit on the length of all stubs, which is about five times the limit per stub.

In practice, if the toral bus length s no more than 5m then stubs 1m long should not be a problem (with the total length of all stube being no more than 5m).

All this will change if in future we need to enable bit rate switching in order to improve throughput.

@gorf26
...what engikeneer said,
use smaller layer height but print infill at every 2nd layer only, to safe some time.

@geneb said in Weird issue after 2.x -> 3.0 -> 3.2.2 upgrade on Duet2 Wifi...:

What part of "I don't want a work-around" is unclear?

You're welcome for the helpful suggestion by the way.

@d0minik96 said in 3D Touch affects Heater 1 Sensor:

Would it be possible to share the ground in the Duet board aswell?

Only if you accept less accurate temperature readings at high temperatures.

You can share the positive supply to the heater and fan(s) if they all use the same voltage.

@Judgment_Kazzy
I started using it, but with a different motor (ACT 36HS2418). I use 710 steps/mm and 60mm/s retraction speed. All other settings like jerk and accel aren't tuned yet, but my findings will be irrelevant anyway for use with the standard LDO motor.

@phaedrux You're right! Nice day

UPDATE: Duet Web Control appears to work 100% fine on FireFox. For some reason, Google Chrome was blocking DWC. I realized this when I attempted to log into my router, and got a blank page as well - the problem was not isolated to DWC, but rather to my browser. Thanks to @chrishamm for suggesting I check my router!

@dc42 Found the route cause of the problem. Entering single G1 commands into the DWC is not enough to test the acceleration and jerk settings. I swapped to a build file with G1 commands that swung the rotation axis side to side over 10, 45, 90, 180, and 340 degrees and that required me to drop the jerk and acceleration to lower values.

Not having the high jerk value does however make it much harder to merge the rotation into the end of the vector as the linear axis is decelerating and the rotational speed at the jump in point must be no higher than the jerk setting of the axis... Going to think this over and write it up a little before asking more questions on that in a seperate thread!

@deckingman

Yeah - 6mm belts can definitely drive those masses!

My experience for the past year has been that as long as the pulley is mounted as close as possible to the motor, no bad effects have been noticed on my largest machine that I haven't upgraded to double shear yet. On the smaller version I made of it, I made a double shear support that floats with the motor casing to keep it from bending and causing issues. So Far, So good, and it spins plenty fast and tensions as high as you'd like it. 20210610_075332.jpg 20210610_075321.jpg

The belt dust is from when I had a light interference with the belt from the edge, which I fixed with a deburring tool. Now we're at low clearance 😄

@auré Please start a new thread with more details.

@mrenz999 said in Independently leveled Z axis Issue:

@fcwilt I will answer for me. No, my issue was never resolved.

This is a very long thread with multiple people involved. If you're still having some issues, please start a new thread with all the relevant info and we can take another go at it.

I would also be very interested in using the Y-axis for probing on my belt printer.
I've already got the BLTouch running but now I am having problems using it for probing.
What I have done so far:

Setup for BLTouch on a SKR Pro V1.2 running RRF:

M574 Y1 S2 ;Setup Y as probe ; Y-Probe M558 P9 H6 F120 T8000 X0 Y1 Z0 C"^probe" ; enable Y probe, set dive height, probe speed and travel speed M557 X50:170 Y0:10 S20 ; define mesh grid G31 X34.4 Z9 Y0 ; BLtouch offset M950 S0 C"servo0" ; Setup servo 0 as servo port on SKR

Homing Y is a workaround because probing does not work at the moment

G91 ;relative positioning G1 H2 Y-15 X15 F50000 ;lift y relative to current position G1 H2 X50 Y50 ;Move X M401 ;deploy probe G1 H1 Y-285 F2400 ;move Y down until BLTouch is triggered G90 ;absolute positioning G1 Y4 F50000 ;Backoff 3mm G4 P500 ;wait for 0,5s M401 ;deploy probe G1 H1 Y-285 F200 ;move Y down slower until BLTouch is triggered M402 ;retract probe G1 Y10 F50000 ;lift y

Using G29 and G30 moves the Z axis, which in my case is the belt, so probing can't finish as the y axis rather than the Z axis has to be moved.

I've tried a custom bed.g in combination with calling G32

M561 ; clear any bed transform G90 G1 X170 Y5 G30 P0 G1 X140 G30 P1 G1 X110 G30 P2 G1 X80 G30 P3 G1 X50 G30 P4 G1 X20 G30 P5

But that also doesn't work out unfortunately.

I am thinking of changing the motion system to CoreXZ instead of CoreXY just for the purpose of probing and then switching back to CoreXY but that would probably mess up the heightmap for using it with Core XY kinematics. Is there maybe a more convenient and more simple solution for this problem?

Is it maybe possible to create a heightmap sort of manually?
For instance using

G1 H1 Y-285 F2400 ;move Y down until BLTouch is triggered

saving the trigger height as point 1 and then move the the next point and do the same steps multiple times until you get a decent heightmap of the y axis (5 would probably be sufficient).

@ccs86 here’s a thread about the Pico version: https://forum.duet3d.com/topic/23461/anybody-wants-a-stepper-motor-analyzer?_=1623217766458

Ian

@jay_s_uk I completely missed that this was an SKR board.

@jay_s_uk I created the mesh.g file, and modified accel and jer there for mesh calibration the restore the original values to normal after the G29 S0 command .

You should be able to send the commands at any time and they should take effect without a reboot.

What problems are you having with tuning?

@tecno said in New parts - PT1000 - BMG:

@siam

PT1000 does not need any adapter board.

oops in this case i have overlooked the last 0 so forget the first answer

@o_lampe

Over the first post there is a topic tools gear button ( Right , Top ) .
Select ask a question, then select topic solved .