Topics created by tekkydave

@dc42 Brilliant - now working.
Thanks
Dave

I use some thermal pads under the glass when I need it. It sticks well to the magnetic surface.

@tekkydave said in RRF 3.3beta2 Macro Parameters:

Is this just a consequence of it is not yet being possible to query a parameter name to check whether it exists?

Yes.

Ok, that's interesting about the uptime. I realise my solution would have to wait for variables.

I also just discovered that I can use the M291 command to periodically check with the user if they want to continue. It's a useful workround for now.

Just upgraded to 3.01RC11 and the bug is fixed.
Many Thanks 🙂

@richardmckenna said in Forum Software: Emails only for new topic posts?:

@tekkydave You can subscribe to a digest, either daily, weekly or monthly in your forum settings.

I subscribe to the daily digest and get an email around 5pm GMT with a list of latest topics.

Thanks for the suggestion - I will try it and see how I get on 🙂

@droftarts said in Issue converting bed.g to use Conditional gcode:

@tekkydave I've just realised the example code is for a delta printer, which doesn't use M671 (no leadscrews) to limit correction, so hasn't been considered in the description or writing of the code. I've updated the page to reflect this.

NOTE: If you use this method to iterate the levelling of a bed/gantry mounted on leadscrews (eg Cartesian, CoreXY etc), the maximum deviation corrected is still limited by the S parameter of M671 (default 1mm). If the maximum deviation exceeds this limit, the script will exit with "Error: Some computed corrections exceed configured limit of 1.00mm", as it would if G30 bed levelling was called manually.

https://duet3d.dozuki.com/Wiki/GCode_Meta_Commands?revisionid=HEAD#Section_Using_conditional_GCode_commands_in_bed_g_to_calibrate_a_delta_printer

Ian

Thanks 🙂 I realised the code was for a delta but adapted it to the commands I normally used in bed.g. I didn't know delta's don't use M671 so 😝 to me for using it in the wrong context. I was keen to have a play with conditional g-code.
Dave

@chrishamm Yes, confirmed fixed. Many Thanks 🙂

Found this old post that gave me a hint.
So sending the following

M106 P4 M408 S0 R1

to Duet via the Panel Due port gives me the data I want. Response to the M408 is

{"status":"I","heaters":[21.5,21.1],"active":[0.0,0.0],"standby":[0.0,0.0],"hstat":[0,2],"pos":[0.000,0.000,0.000],"machine":[0.000,0.000,0.000],"sfactor":100.00,"efactor":[100.00],"babystep":0.000,"tool":0,"probe":"525","fanPercent":[0.0,0,0,0,24,100,100,-1,-1,-1,-1,-1,-1],"fanRPM":[-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1],"homed":[0,0,0],"msgBox.mode":-1,"seq":20,"resp":"Fan 4 (Enclosure Fans), speed: 100%, min: 40%, max: 100%, blip: 0.10, temperature: 26.0:65.0C, sensors: 2 3, current speed: 40%:\n"}

with the message text in the "resp" field at the end of the JSON response. Just need to extract & parse to get the value I want (40%).
The reason I'm doing all this is to put a simple 20x4 LCD on the front of my Duet enclosure showing some basic info. Especially the hotend fan speed as the fan I now have on the Titan Aero is so quiet I can't tell if it is running or not (Noctua 40x20mm). The stock Titan fan sounds like a jet taking off in comparison. 🙂
I want to also develop some kind of SMS or email messaging out of the connected RPi to warn of certain conditions or let me know when the print has finished (I'm usually sat in another room watching the telly).

@dc42 said in RRF 3.0RC1 Z Homing Issue (Analogue Mode):

I think I have found the reason for the problem, although I don't have a printer using an analog probe at present so I can't test the fix. Please try the Duet2CombinedFirmware.bin file at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.

Yes, that has solved the problem. Many thanks and a Merry Christmas 🎅 😃

RRF3.3beta2 has resolved this issue. G30 now probes at full speed due to changes in M558 F parameter.

I can confirm that DWC 2.05 has fixed this issue 🙂
Great work & thanks.

@tekkydave 2 screws are just too hard to balance. I recently tried just having the rear wheels and removed the front wheels because I was having some banding issues crop up. It didn't help the banding and the bed became less stable.

As long as the lead screws are vertical and aligned with the bed mounts and the wheels are aligned and tensioned first it seems to be very smooth and stable. In the end I think the banding was caused by a lead screw mount or bed mount getting pulled out of alignment when I retightened the bolts.

The double bearing blocks I'm using definitely over constrain the lead screws and the bed mounts are also fixed. And there is very little play with 1mm pitch screws. The alignment needs to be perfect. I would like to switch to pillow blocks which have some inherent play in them and Oldham style bed mounts but I haven't found any I like yet.