@hevilp See your other thread for why it reports 0.

If you send G31 T8 it will report the current settings.

Thanks for the input, guys. I've since had a brief conversation with Haydn, and he stated that he hasn't had a single request for larger diameter arms in 360mm length or shorter. He did state he's done larger diameter with longer arms, though. He again stated that his normal 0.230" is plenty sufficient for 360mm & below, and likely somewhat longer, too.

I did see on his site that he recommends a dab of lube in each joint (he applies with a Q-tip). I think I'll try that soon.

@snowcrash said in FSR Controller Module for Auto Bed Leveling:

So, assuming I have version 2.01 of the firmware, I can use: M42 P60 S0/S1 to control pin CS5, and M42 P65 S0/S1 to control pin z_mod_probe? Is this correct?

Yes, but you will have to wait for 2.01beta3 to use M42 P65.

@boldnuts I use a carriage mount solution for my P3Steel see my thingiverse link I posted earlier...

Hi,

Sorry to hear you're having problems. Can you post a photo of your current piezo setup? I have a couple of things to suggest/check.

Do you have delay before probe enabled? How long?

The kind of random failure you're describing could be caused by a loose wire or poor connection.

Rather than measuring the resistance of VR1 can you measure the resistance between the solder points on the piezo while the piezo is plugged in.

Idris
(Precision Piezo)

I think to give a fair impression and manage expectations somewhat, some users find there are a few hours of tweaking required to get reliable performance, and unless you have a very accurate machine getting 0 microns range and 0 microns std deviation is rather optimistic (but great result - still very pleased), something between 5-15 microns range and around 2-4 deviation would be more normal.

But once tuned it is a game changer in terms of reliable levelling/tramming/calibration/compensation.

Thank you for investigating this.
I don't use the bltouch anymore so I can't give a fast feedback if you have found a fix.
I can mount the bltouch again for testing it, but that may take a few days then.

@vhoward @Scachi

I have added line to the guide, see this post
https://forum.duet3d.com/post/50206

Yes I think getting rid of springs can help. Play around with probing speeds too. Too slow and you don't get a trigger, too fast and you lose accuracy. Sorry for not picking up this one earlier I've been away travelling.

I used them to eliminate a salmon skin texture on curved surfaces on a i3 cartesian with DRV8825 drivers. It was only the 4 diode version, but it helped enough.

@dc42 Thanks!!!

It seems that my caliper takes off measures above 140mm and I didn't noticed the first time (I mostly use it to take extremely small measuers). The homed height defined on M665 was higher by a couple of centimeters. Also the H parameter on M558 was too low, so all added up, the probe was expecting to trigger below the bed. I used a more analog method to take measures and it helped to solved the issue.

My biggest mistake was to think that the probe will trigger at any height regardless of the other parameters, so I didn't think about checking the heights on those commands. Once you point me in the right direction I was able to quickly solve this issue.

Thanks again!!!

Marcos

@saadiqj I mean that where you use G1 S1 Z-370 to move the bed use G30 to call for a probe instead.

https://duet3d.dozuki.com/Wiki/Gcode#Section_G30_Single_Z_Probe

Here is my HomeAll.g for comparison.

; homeall.g ; called to home all axes ; ; BLTouch prep so we don't catch the probe pin on the edge of the bed ; M280 P3 S160 I1 ; Alarm Release and Push-Pin UP just in case it's in alarm and deployed M402 ; Retract probe just in case it's down ; Home XY for Z homing ; G91 ; relative positioning G1 Z5 F200 S2 ; Lower bed 5mm to ensure it is below the switch trigger height M913 X50 Y50 ; set X Y motors to 50% of their normal current for homing G1 S1 X-375 Y305 F4000 ; course home X or Y G1 S1 X-375 F4000 ; course home X G1 S1 Y305 F4000 ; course home Y G1 X2 Y-2 F1000 ; move away from the endstops G1 S1 X-10 F200 ; fine home X G1 S1 Y10 F200 ; fine home Y M913 X100 Y100 ; set X Y motors to 100% of their normal current ; Z homing section follows ; G90 ; absolute positioning G1 X190 Y90 F4000 ; Move x and Y axis over to bed center so probe is on top of bed ; Set lower speeds for homing M566 Z5 ; Set maximum instantaneous speed changes (mm/min) (Jerk) M203 Z350 ; Set maximum speeds (mm/min) M201 Z100 ; Set maximum accelerations (mm/s^2) ; Probe the bed ; M558 A1 F350 ; Set single probing at faster feed rate G30 ; Do a single probe to home our Z axis M558 A10 F100 ; Set tripple probing at slower feed rate G30 ; Probe again to get a more accurate position ; Set normal speeds again M566 Z60 ; Set maximum instantaneous speed changes (mm/min) (Jerk) M203 Z600 ; Set maximum speeds (mm/min) M201 Z600 ; Set maximum accelerations (mm/s^2) ; Move X and Y back Home ; G1 X0 Y270

I think I have found the reason why the probe wasn't working right, as I had the M558 and the G31 in the wrong order. RTFM!

To specify which probe you are setting parameters for, send a M558 command to select the probe type before sending the G31 command, or use the T parameter.

So, fingers crossed, it's working OK now.

@dc42:

Is there any reason why the Javascript code can't be run client side instead?

In theory, it could all be client side. For example, Chilipeppr works this way*. In practice, that would be a huge change to CNCjs.

As a "never before had a pull accepted", I feel it would be prudent to "go with the flow" for the moment, and add native Duet support to the way CNCjs is structured. After that, add a TCP/IP connection option.

And… there is always the Windows, Mac, and Linux stand-alone versions. No server is needed at all. With those in play, I'll say that "all browser side" is somewhere between third priority and no real need to do it at all.

.
.

Chilipeppr runs entirely in the browser, EXCEPT for a small program that provides the serial USB connection (browsers won't let Javascript control serial ports). Obviously, with a TCP/IP connection, this would be come moot.

@AlexLin:

for the interested this is the phone mount. I doesn't include the 3030 mount but that is easy to fix
https://www.thingiverse.com/thing:2194278

Great! Thank you!

Good! Thanks.

hello

I was playing with similar idea and have found that for FSR to be consistent you really have to slow down the speed.

https://youtu.be/zBXN_6AAWp0

By default you need to send line numbers and checksums when sending data to the PanelDue port. This is to guard against character loss. You can turn off this requirement using the M575 command.