Advanced Search

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.

The only concern I have is why my hip has been so sore this week.
On a serious note it's great to see someone getting involved and fixing the stuff that can fall through the cracks.

Hi all,
I experimented with the mqtt-publisher on a trial basis. It works well so far, but I can't publish more than 10 HAL pins. Even if there are more than 10 parameters under keys=, only the first 10 are transmitted. Does anyone know if I'm doing something wrong? I followed the mqtt-publisher instructions exactly.
Thanks for help
Peter
 

Thanks about the gedit thing, I can add the repo for Ethercat same way all the other ones are done.