Advanced Search

I use LinucCNC Version 2.9 and the macro-version is 3 or 3.1. 
Is there a resulatuion that works better than others?    

you can also set the ini defaults in the setup gui:

@Russell should work, but modbus is very very slow, so not usable for things like servo motors.

@mBender:

you can overwrite all ini parameters in the json config and also add MDI commands:
you can also add your own .hal file to postgui_call_list.hal (this entry will not be overwritten)

# cat Output/TangNano9K/LinuxCNC/postgui_call_list.hal

about the laptop/PC, try to reinstall the rio.c component:

Thank you so much PCW and tommy
PCW would that mean I don't connect 22 - SPINDLE- to COM, instead connect OUT4B --> COM and OUT5B --> COM?

Could you share your 3D CAD model? If not, it's not a problem.

Cheers Hakan. I'll have a read through and see what I can come up with.

Edit:
Looks like I need to convert to a U32 unit (for the duty cycle). Hopefully I can get something working within the next few days. 

As far as I'm aware, motion.probe-input only causes the "probe tripped during non probe move" message if the pin goes high during a non-probe move, not if it's already high.
(I know you figured that out, just wanted to state directly that in theory there's no issue with a non-probe move which starts with the probe triggered)
The real issue is, as Andy says, is that the raw probe input is going to bounce and cause the "probe tripped during non probe move" message, and halt the subsequent move/jog.

But, actually, most of the time this behaviour occurs during probing, it's during the deceleration phase of the probe move itself (as you mentioned). This was opened as an issue last year:
github.com/LinuxCNC/linuxcnc/issues/2926
While you can work round this in hal in various ways (many already discussed), ideally I think this should be patched.
When I had this issue I also thought the same as the title of this post, that the probe must be triggering during the pulloff move (on account of the message wording) when actually it was occuring during the probe move itself. This is confusing and the "probe tripped during non probe move" message is somewhere between misleading and incorrect in this context.
The way I see it is that the deceleration phase is definitely part of the probe move, since you can't have a probe move without deceleration. Therefore, it doesn't make sense to claim that a trigger during a probe move deceleration phase should be treated the same way as a trigger during a jog or commanded non-probe move. The fact that this behaviour only seems to be worked around definitely supports this view.

But I get how this might be complicated to patch if it is the case that the motion type can't stay as "probing" and so is set a different motion type, which causes this issue.
I'm assuming that the fix isn't as simple as keeping the motion type as "probing" after the first trigger, because then subsequent bounces would also be registered as triggers to update the probed position variable? And that definitely isn't ideal, if you commanded one probe move, you shouldn't get several updates to the probe result when only the first one is the canonical result.
So ideally you'd just want to set a flag in the motion type used during deceleration to ignore further probe inputs until the end of that move? Or create a new motion type for "probe decelerating" which has this applied by default?

Either way, this doesn't solve the issue of bouncing during the subsequent pulloff moves. But since the pulloff move is typically at a much higher feed, it's far less likely to be affected by this issue.

And yeah, debounce does work for this, and the increased latency isn't actually a huge issue (as long as it is repeatable) if you calibrate the probe on a known artefact at the probing speed(s) you're planning to use. Probe Basic has this built into the probing routines.

But re. your flipflop logic, you're essentially using the same logic I'm using, which is the "dsmono" component from this comment here, which also makes the the probe "sticky":
forum.linuxcnc.org/24-hal-components/423...rrors?start=0#269004 
(In fact I'd recommend reading that thread from the top, lots of good info)
I think the advantages of dsmono (or implementing the same thing using EDGE) over your component are that you don't need to add M64/M65 to your probing routines, and the pulloff move is protected once the "sticky" period expires.

Ok once again.

For the interfaces you want to configure via Network Manager make sure the interface does not have an entry in the network file.

It is quite simple.

This version built on Flex, where would I find the .ui and .py files?