@deckingman You are guaranteed if you need a specialised tool to finish your job, you will never find it until you buy a new one to replace it.

Screenshot (2).png
@fcwilt they are at the bottom of the corner pieces and are activated with a foot on the carriage and the entiere homing system is about 25mm high

@dc42

oh this is even better! thank you! now i can start to make sense of what the values mean.

Sorry to resurrect an old thread. My company began to require us to come back to the office now that everyone has been vaccinated. Sucks because it really cuts into my 3d printing time 🙂

ANYWAY. @dc42 I did exactly that as one of the last things I tried. I still get 1-2mm of difference between towers. I have a heavily modified Rostock Max and even gone as far as to put belt tensioners on the top to ensure proper tension.

I have found that instead of equally tensioning the towers I can tension them to get equal movement, but that really doesn't seem like the right thing to do. One is very taught while another seems to be quite loose.

I suppose you could argue that mesh leveling would sort that out, and to a point it does but I still get some discrepancy the further out I go between the XZ towers, everywhere else is great.

Seems a lot like the individual arm length is the culprit but I've moved the arms around and the same issue exists in the same place. Side note, I've even tried to rotate the effector, same thing. To me this would then maybe indicate that one tower is off with regards to steps/mm (or whatever has a direct effect on that measurement). Sure enough there is a significant discrepancy between all of them, with more on the Y tower.

So far I haven't 100% tracked this thing down, I can solve by printing a raft and the print comes out great, and dimensionally accurate.

Any other suggestions of what to try? Before you say it, I have confirmed with an engineer square that the towers are square and the build is rigid.

@dc42 does RRF support the Maslow CNC router style kinematics? It's essentially what's been discussed here.

Been thinking about DIY building one of these for quite a while. Future larger workshop means it's a practical proposal.

https://youtu.be/y60q6U7NjTQ

Works again. thanks 😉

@aitor said in How can I verify that a file exists:

I really wanted to use the M291 command in my resurrect-prologue.g as S3, "ok " to continue and "cancel" to not continue, but I have not been able to, so I have had to do this less nice alternative for now.

Maybe this will help?

https://forum.duet3d.com/topic/23423/m291-solution-to-handling-both-ok-cancel

@dc42 Thank you for your reply!
I will lower the motor current to 600 with RRF and upload the zip file to Duet.

@farmer-3d I think you need to swap the TxD and RxD connections between the Duet and the ESP. Duet TxD should go to ESP RxD and vice versa.

Also for safety I suggest you connect 1K resistors in series with each of the TxD and RxD signals between the Duet and ESP. This is to protect them when one of them is powered and the other isn't. You don't need to do that at the PanelDue end because PanelDue already includes series resistors.

It seems like my best option is try and setup a wifi router for a local network, but not connected to the internet. Then I can connect the duet boards to the local wifi, would each board have its own I.P.? I could then have multiple browser tabs with the different I.P. addresses to switch between them.
Each one would need a raspberry pi to connect a camera to it. And its own wifi plug to turn off the power to the heated bed.

Or, I can get the Duet 2 LAN boards and a LAN switch connected directly to my desktop. (But how would I connect the raspberry pi and wifi switch to it?)

Thanks for the comments so far!

@dc42 Yeah, thanks I just noticed. I really really appreciate the help.

@dhusolo I have the same problem with dyze extruder, something new about your PID tuning ?

@jay_s_uk It work thank you !

@vwegert I think a couple of things happened at the same time, which caused the problem:

You uploaded the 3.3 zip file under 3.2, so files get put in the 'sys' folder The update to 3.3 went okay for firmware and DWC The WiFi firmware failed to update (it happens, there's no error checking in the ESP firmware update process) Now on 3.3, you tried to update the WiFi firmware again, but the firmware folder hasn't been created (it only happens if you subsequently upload a firmware zip or bin file in 3.3), so the firmware can't find a relevant file.

You found one workaround, which is to create a firmware folder and add files. You can also (since RRF 3.3beta2) use the 'P' parameter in M997 to provide the absolute path and filename to use. See: https://duet3d.dozuki.com/Wiki/Gcode#Section_M997_Perform_in_application_firmware_update

Ian

Further update to my issue, I've stripped my top end apart, as a correction the motors installed are 17HS15-1504S-X1 (the 5's look like 6's) these are rated at 1.5 amp.

All coils measure approximately 2.3 ohms taking into account lead correction so within spec.
both motor leads tested with no breaks or high resistance found, and the crimps appear secure, one lead measures 102cm and the other 99cm, would 3 cm make any difference given they are running on different drivers?

my hot end moves freely on its rails and all my pulleys follow suit, I'm now thinking this is a board or firmware issue, I cant see any burnt or popped components on the board although it is still installed so I cant rule this out yet.

I've run P98 on my config and multiple M122 during faulting and after with nothing I can spot with my limited knowledge, is there any other diagnostic tests I can run?

Regards Jim

@fcwilt
Screen Shot 2021-06-18 at 5.46.31 PM.png Screen Shot 2021-06-18 at 5.46.23 PM.png
it is up and running 🙂

@maxgyver

I use the filament handling feature of the DWC to deal with these sort of issues.

If you wish to use a temperature other than the printing temp for a given filament you could use the variables feature of firmware 3.3 to allow that.

Frederick

@o_lampe said in 3.3 RC3 Error when babystep in DWC:

Babystepping should be able to go beyond limits (again)!

Given that the first layer Z height is the layer height needing more than that amount of adjustment (0.15, 0.20, etc) would seem to indicate that something is not right.

Frederick

@Phaedrux @dc42

Warning: Turning on the print cooling fan did not increase hot end cooling. Check that the correct fan has been configured.
Auto tuning heater 1 completed after 3 idle and 10 tuning cycles in 1505 seconds. This heater needs the following M307 command:
M307 H1 B0 R1.829 C407.7:407.7 D20.33 S1.00 V24.0
Send M500 to save this command in config-override.g

I have the following message after PID tuning, I reduce de R value by 20% and still the same problem

@moe-adams9093 neither of the above. it connects via SPI
I suggest reading this thread https://forum.duet3d.com/topic/17203/duet-2-ethernet-and-sbc?_=1623998246872

@dc42
Problem solve with bossa and reflash the firmware, but now when I home my axis go back twice in the oposite direction...

I have not the problem with the firmware 3.2.2

My home.x for example :
G91 ; relative positioning
G1 H1 X1005 F1800 ; move quickly to X axis endstop and stop there (first pass)
G1 H2 X-5 F1500 ; go back a few mm
;G4 S0.5
G1 H1 X6 F600 ; move slowly to X axis endstop once more (second pass)
G1 H2 X-5 F1500
G90 ; absolute positioning

To correct the problem I add a G4 S0.5 when the problem occur but I think this is not the good solution.

and when I send the command one by one erything work well

@egon-net also a screenshot would be handy.

@paralepsis said in [3.3.0] My tool disappeared after 3.3.0 install (?):

How do I correctly define there to be no part fan?

What are you trying to achieve? If you want M106 commands in the GCode file being printed to be ignored for that tool, then you would have to define a dummy fan number and use that in the M563 command. If you don't specify a fan number at all in M563, then M106 without a P parameter will default to controlling fan 0 when that tool is active.