Topics created by garyd9

@aerouta I use a 3510 fan for the print fan and a 2510 fan for the hotend fan. I was able to make a 40mm fan work for the print fan, but the clearance was too close for comfort. I find 35mm works nicely. I also replaced the 5V stock Revo fan with a 25mm 24v fan. 25mm was the smallest size I could find that operated on 24v.

Hotend Fan
PXL_20221220_012917824.jpg

Print Fan
Untitled.png

The models are parametric, so they can be made to fit other fan sizes. I'm happy to share them if anybody is interested.

25mm Hotend Fan STL 35mm Print Fan STL

@garyd9 yes, absolutely... it's in preparation. cannot confirm yet an exact timeline.

@fcwilt Sorry - I mistyped. " and then run bed.g via G30." should be " and then run bed.g via G32."

@paulhew

I still have this issue and I do not know how to fix it still.
I thought it was to do with Touchpanel firmware, but it happens in DWC also

Here are the details and the macro.

Duet Mini5 and 1LC - SBC mode. PanelDue 7i

m115 FIRMWARE_NAME: RepRapFirmware for Duet 3 Mini 5+ FIRMWARE_VERSION: 3.3 ELECTRONICS: Duet 3 Mini5plus Ethernet FIRMWARE_DATE: 2021-06-15 21:46:20

This is my macro

M291 R"** SHUTDOWN **" P" Are you sure you want to SHUTDOWN the printer and Pi?" S3 M106 P10 S0 M7722

Still ignores the cancel 😞 and informs me Linux is disconnected.

Just tried it from DWC and clicked cancel it and it carries on and shuts down.
I think mine is either a firmware or DWC issue.

Hope someone can assist me and others that are struggling to cancel M291 commands.

Regards,
Paul.

When I think about it, I think the last time I cleared up the ripple as you see in the height map was actually solved by swapping my magball arms around. Accumulated errors between carriage + arms+ effector made measuring arms with magballs in them unattached to the actual build a trap, I had to measure from the rail to the ball end, then from ball end to ball end, then put the arms in the right position to get most uniform pairs on a tower as well as best average length. For my magball arms (360mm haydn huntley magball arms), what threw me off was the effective pivot point. For my set at least, If I measure the arm with a 9.5mm ball stud on each end from the edge of a ball to the other edge of the ball, the firmware measurement is that distance minus 7 (plus corrections for effector/carriage errors). Why 7? Because (once again for mine at least) the 9.5mm ball is inset about 3mm into the arm, and the effective pivot is 3mm further in from the edge of the arm, leaving 3.5mm from each ball end to subtract on each side. My desire for things to work neatly kept driving me to think it'd pivot in the center of the ball stud which is not the case. Figuring that out was so frustrating I think I want to forget it again.

I use stand alone, no touch screen, trough ethernet. Work like a charm..
After struggling with sbc for months I find stand alone much faster and also I can and supervise all of my machines from different web browser pages.
I just added a monitor to my computer and split the screen in 6.
Using remote desktop I can access all of them from anywhere and anything including my cellphone.. cant complain.

@dc42 said in conditional g-code, alternative to curly braces?:

M207 S{{move.axes[0].workplaceOffsets[1]}} R0 F{{move.axes[1].workplaceOffsets[1] * 60}} T{{move.axes[2].workplaceOffsets[1] * 60}}

I can confirm that doubling the curly braces does appear to work. Thank you.

Gary

@garyd9 said in Bug in 3.2.2: X/Y/Z positioning wrong in DWC and PanelDue:

Of course, now that you've told me switching to machinePosition is as trivial as a click, I might not care. 😉 I wonder if @wilriker would be willing to add a similar toggle to PanelDue.

I intend to provide this possibility but due to the limited screen estate I have to carefully work out where I can make space for a button or similar.

Yes. That's all that's required

@Phaedrux said in G10 hardware retraction and z-hop:

I believe it's retract then hop.

Yup: https://forum.duet3d.com/post/201684

thanks - I've submitted an edit to https://duet3d.dozuki.com/Wiki/Gcode#Section_G10_Retract (and G11) clarifying the order.

"Retracts filament then performs any zlift/hop according to settings of M207."

"Unretracts/recovers filament after undoing any zlift/hop according to settings of M207."

(The "zlift/hop" term is taken from M207. )

Sorry for showing my ignorance of delta machines. Not intended to hijack. Back to topic. Thanks for the report. Will move to the beta forum for further investigation.

@Phaedrux said in Cura, firmware retraction and M207:

That's a clever work around. It'll be exciting to see what people come up with when actual variables are introduced.

I'm actually afraid of that. I generally slice models once and leave them on my duet's sdcard for all time. (That was one reason for changing my stuff to use firmware retraction.)

Once variables are implemented and working, I'll have to go through and edit all my gcode files and macros to use proper variables instead of crazy hacks. (I can't assume that the hacks will always be supported.)

@chrishamm said in DuetPi - SBC/Chromium chewing CPU cycles:

That sounds odd - the new update delay should have reduced the CPU usage notably. Do you have the latest Chromium version from Raspbian installed (i.e. did you do apt update/upgrade recently)?

yes - in fact, before posting the above I ensured that chromium, etc were all updated.

I'm using the default repos from the duetpi image (so, no unstable stuff.)

@dc42

Thank you for replying. It's over a year old (and not scratched that I'm aware of.) I'm starting to think it might be related to the "zesty nimble" adapter I have bolted to the top of the smart effector via the three inner holes. (Using M3 screws/nuts and nylon washers to prevent metal to PCB contact.)

I'll try to loosen those nuts (and check my wiring) and if that doesn't help I'll consider replacing it before it goes bad.

Thank you again
Gary

The last G0/G1 ... Z code is too far from the end of the G-code file (-418284 chars). DSF scans only the last 256KiB (~262144 chars) and RRF scans even less. But you can increase this limit in /opt/dsf/conf/config.json via key FileInfoReadLimitFooter. If you double that value, it will scan the last 512KiB which would suffice for your particular file. Note that file info parsing may take longer though.

Everything compiles fine with just dotnet 5.0 installed.

I also took an hour to grab the August 2020 RaspPi OS 64-bit image, set it up, updated it, adding the duet servers, and installed DSF on it. It seemed to pull arm64 (aarch64) binaries via apt and they work fine. (I didn't try to recompile with arm64, but I don't see any reason why the compile wouldn't work.)

At this time, I'm not sure if there's any advantage to using the 64bit distros with DSF. I didn't notice any, but I only went to far as to installing it and making it sure it talked to my printer. Once I saw that chromium is just as resource hungry on arm64, I pulled that sdcard out and put back the 32bit one.

I think that's all the questions I posted above, so I guess I'll mark this as solved.

@droftarts @Phaedrux Screenshot_2021-03-25_at_16_49_25.jpg

5 x 2 Dupont block.