Advanced Search

0.97mm calibration offset is HUGE, you have wrong going on there, that should just be the trigger distance of the probe. You should use a larger calibration object so you aren't in an acceleration state. The cal offset should be a really small number, 0.04-0.08mm for most decent mechanical hobby probes. The probe tip diameter must be entered into the tool table in the column. (I this is where you're issue is coming from and why your cal offset is so large. Use only fast probe feed rate (set slow probe feed to 0.000). Use something like 200mm/m fast probe feed rate.. Be sure to reset the offset prior to running calibration. Run in probe position only mode for calibration. Make sure your step of width is a decent amount past the edge, at least 10mm or so.

Whatever is the lowest you might use.
Last china one i had needed 3 turns to work reliably at 20A, and that was the lowest it could be set despite the knob being marked as 10A as well as showing 10A on the display. At 33A shown/set it would do 45A, and at 60A it would do 60A.

I haven’t run my ect60 drive for more than 30 minutes, so I haven’t seen this problem.

I appreciate all your documentation however. I’m also running a pi4b.

When you installed the Ethernet switch, did you maintain the series cabling for all the drives? Put another way, do you have just the pi and the first ect60 connected to the switch?

I wonder if a loop configuration using the Ethernet port on the pi, plus one more usb dongle Ethernet port would also solve the problem.

I probably worded the statement poorly - but the table, vise material column is 100% trammed with each other no question


I would just disregard that statement, what I meant was when I probe the corner the probe does appear to be in the correct location, at least close enough that if I brush the probe along that wall, the ball (whose central axis is now along X or Y) deflects enough to re-trigger, meaning the probe is fairly close to the true corner.

However, the easier statement is that when I compared the origins, the probed origin is around 0.815mm off the true corner (as compared to using a mechanical edge finder). So for some reason, when I use my probe, the origin that is recorded is 0.815mm AWAY or INTO the actual wall.

I use a dial test indicator to make sure the probe ball tip is concentric so its definitely not that.


Can there be some issue in probe-basic or linuxcnc that is not correctly applying the diameter? Or miscalibrated somehow internally but on the UI shows the correct value??

I only tried at 45 amps. How low is worth testing? 

Try this for the keys

I see what you mean, even when it starts with multiple key entries only the last group of keys get sent

ffffrf wrote:

also if I use the probe to probe the edge, then move to the origin and slide the probe across either X or Y wall of the metal at the 0 value for that axis, it does retrigger the probe, doesn't that mean the probe is functioning correctly and its a linuxcnc side issue?

No, from what i can gather it means the machine/table/material is not trammed properly.
Or what am i missing?

Hey so I did another test - setting the origin manually with an edge finder makes it work as expected.


However, I can't for the life of me think of what the actual issue is in that case then? The probe calibration all looks correct, the diameter is set in the tool table.

When I compared the edge finder origin vs the probed origin, the probed origin is about 0.815mm off in each of the axis. The probe diameter is 1.95mm, calibration seems correct.

Do you think it is more likely a probe issue or a linuxcnc issue? Clearly the post processor/CAM is correct

I just can't think of anything mechanical with the probe being the actual issue

edit: My probe tip diameter is 2mm, when I do probe cal it says the probe cal offset is 0.97mm - and measures the circle as 5mm

EDIT2(MORE IMPORTANT): also if I use the probe to probe the edge, then move to the origin and slide the probe across either X or Y wall of the metal at the 0 value for that axis, it does retrigger the probe, doesn't that mean the probe is functioning correctly and its a linuxcnc side issue?

bentiggin wrote:

Do you think using a reed switch would have much of an effect on pierce delay?

No, they are pretty fast but i can not recall the exact Ton/Toff time, it was 40 years ago when i started using them, but i am sure it is negligible.
You might have another issue, failing to trigger, so did you check that it does reliably trigger at lowest current setting?

Once you get hypersensing figured out its a no brainer float switch is your backup, Hypersening allows you to probe surface so quick its scary, I use Hypersensing to set tool height offsets on my router had to modify the g38s with digita on offs to stop the probing erros i think theorically it is the most accurate method with known physics to measure that i have a isolated touchplate mounted to the machine and just set up my work offset with my probe then ehen every M6 asks to to load new tool it will check if then go to town untill i get ATC this is the best metod i could think up

I ended up using a reed switch. Worked great.
Ran a few cuts in plasmac and the arc volts read as they should.
No apparent problems with the hf start. 
Tommy, thanks for the guidance and helping me safely work through my confusion.

Do you think using a reed switch would have much of an effect on pierce delay?

I find little bits of time in the morning before work and whenever else I can squeeze out to the garage. I have gotten the machine to the point where it all homes properly granted very very slowly. It then moves to home position. Yesterday I designed a basic control panel for the monitor which I also got the touchscreen this week. I had enough time at to different points in the day to cut and then later bend up and partially assemble the control. Need a lot more time to wire it all up and change the program to use the 7i73 for the control interface. In the future I plan on adding 2 override encoders as well as an mpg either on the panel or on a pendant as well as 2 or 3 USB ports 

When I create multiple “keys=” entries one below the other, LinuxCNC no longer starts:

Preparing LinuxCNC2MQTT info: Publishing MQTT message (devices/linuxcnc/machine): {"halui.axis.x.pos-relative": -84.95, "halui.axis.y.pos-relative": -92.95, "halui.axis.z.pos-relative": 24.496, "halui.joint.0.is-homed": false, "halui.joint.1.is-homed": false, "halui.joint.2.is-homed": false, "mqtt-publisher.period": 10} qtdragon_hd_postgui.hal:30: Unknown command 'keys=halui.estop.is-activated,halui.tool.number,halui.machine.is-on,halui.program.is-running,halui.mode.is-auto,halui.mode.is-manual,halui.mode.is-mdi,halui.mode.is-teleop' info: MQTT connected: Connection Accepted. Shutting down and cleaning up LinuxCNC... task: 526 cycles, min=0.000012, max=0.011844, avg=0.009461, 0 latency excursions (> 10x expected cycle time of 0.010000s) Note: Using POSIX realtime LinuxCNC terminated with an error.
 
My configuration:

loadusr -W mqtt-publisher \
--mqtt-broker=[MQTT]BROKER --mqtt-user=[MQTT]USERNAME \
--mqtt-password=[MQTT]PASSWORD \
keys=halui.axis.x.pos-relative,halui.axis.y.pos-relative,halui.axis.z.pos-relative,\
halui.joint.0.is-homed,halui.joint.1.is-homed,halui.joint.2.is-homed

keys=halui.estop.is-activated,\
halui.tool.number,\
halui.machine.is-on,\
halui.program.is-running,\
halui.mode.is-auto,halui.mode.is-manual,halui.mode.is-mdi,halui.mode.is-teleop

setp mqtt-publisher.period 1
setp mqtt-publisher.enable 1

Peter

FYI after struggling with the files not working for a while, I did find just using http: instead of https: works

Did you notice the bit where each token is limited to 255 characters and to get sound this you can use multiple "keys" entries ?

It's hidden in under the examples heading.
If you have no further luck it may be of interest to raise an issue on the GitHub page.