CNC12 v5.24 RC5 is now available for testing

[cncsnw]

My opinion, for what it's worth:

If the probe and TT share a trip input, then there should be no problem with sharing a detect input (provided the control builder provides only one plug connection).

If the probe and TT use different trip inputs, then it would be reasonable to make separate detect inputs mandatory. Otherwise, there will be situations (such as F4/Auto on the Part Setup screen) where it is unclear which device is expected to trip.

[cnckeith]

My opinion, for what it's worth:

If the probe and TT share a trip input, then there should be no problem with sharing a detect input (provided the control builder provides only one plug connection).

If the probe and TT use different trip inputs, then it would be reasonable to make separate detect inputs mandatory. Otherwise, there will be situations (such as F4/Auto on the Part Setup screen) where it is unclear which device is expected to trip.

and while we are on this subject, i'd like to implement an option to run any probing cycle in a "I don't care" mode. as in "I don't care what type of touch device input trips and I don't care if the probe is a NC or NO probe" While this mode is evoked, probing cycles will trigger off of any touch device input state change that occurs during a probing cycle.

[ShawnM]

On my small 3x5 router with Acorn I have 3 devices sharing the same input. I have both my movable and fixed tool touch offs and my probe all on the same input labeled "ProbeTripped". The fixed one is hard wired to the input and my movable tool touch off and my probe both have the same connector on the cable and both plug into a socket on the gantry and it also run back to the same input. Only the probe closes the "ProbeDetect" input when plugged in. All devices are of course NO devices and this works great and uses a single input. I have not tried this on an AcornSix build yet as I have inputs to spare.

I'm hoping you don't change anything with Acorn that will mess this up going forward.

I like Keith's idea.....I don't care.

[cncsnw]

... while we are on this subject, i'd like to implement an option to run any probing cycle in a "I don't care" mode. as in "I don't care what type of touch device input trips and I don't care if the probe is a NC or NO probe" While this mode is evoked, probing cycles will trigger off of any touch device input state change that occurs during a probing cycle.

You will want to think that one through pretty carefully.

At first glance, it sounds fool-proof, because motion will stop no matter what device is tripped, and regardless of whether the user managed to set up their parameters correctly.

But, as you describe it, you are also eliminating the opportunity to check whether the probe is already in a tripped state before the cycle begins. In that case, your cycle is going to move the probe into the part, waiting for a state change that never comes.

A safer definition might be: don't start until all probing devices are in the not-tripped state; and move until any probing device is in the tripped state. This does require that the tripped state be properly defined for each device.

[cncsnw]

Another note on v5.23 beta rev5:

The Utility menu text still says "... support is avalible".

[cnckeith]

Another note on v5.23 beta rev5:

The Utility menu text still says "... support is avalible".

ah! we fixed that..its back

[cncsnw]

Release notes state:

17. Added PLC IO to the Report Summary

An example report*.txt file contains:

Code: Select all

PLC IO
Ax1_MinusLimitOk Input 0
Ax1_PlusLimitOk Input 1
Ax2_MinusLimitOk Input 2
Ax2_PlusLimitOk Input 3
... and so on

Since the report*.txt file is supposed to be human-readable, I recommend using input and output numbers that count from 1, not from 0. In the above example, "Ax1_MinusLimitOk" was defined to be INP1, and "Ax2_PlusLimitOk" was defined to be INP4.

I also recommend using the native names: "INP1", "INP2", "OUT1", "OUT2". Writing it out as, for example "Output 2" promotes further confusion for Wizard users who already are not clear on the difference between OUT2 and OUTPUT2.

[cnckeith]

Release notes state:

17. Added PLC IO to the Report Summary

An example report*.txt file contains:

Code: Select all

PLC IO
Ax1_MinusLimitOk Input 0
Ax1_PlusLimitOk Input 1
Ax2_MinusLimitOk Input 2
Ax2_PlusLimitOk Input 3
... and so on

Since the report*.txt file is supposed to be human-readable, I recommend using input and output numbers that count from 1, not from 0. In the above example, "Ax1_MinusLimitOk" was defined to be INP1, and "Ax2_PlusLimitOk" was defined to be INP4.

I also recommend using the native names: "INP1", "INP2", "OUT1", "OUT2". Writing it out as, for example "Output 2" promotes further confusion for Wizard users who already are not clear on the difference between OUT2 and OUTPUT2.

thanks, i put this on the v5.30 list.

thought i was going to have a v5.24 RC out this evening but it will be tomorrow.

[cnckeith]

Release notes state:

17. Added PLC IO to the Report Summary

An example report*.txt file contains:

Code: Select all

PLC IO
Ax1_MinusLimitOk Input 0
Ax1_PlusLimitOk Input 1
Ax2_MinusLimitOk Input 2
Ax2_PlusLimitOk Input 3
... and so on

Since the report*.txt file is supposed to be human-readable, I recommend using input and output numbers that count from 1, not from 0. In the above example, "Ax1_MinusLimitOk" was defined to be INP1, and "Ax2_PlusLimitOk" was defined to be INP4.

I also recommend using the native names: "INP1", "INP2", "OUT1", "OUT2". Writing it out as, for example "Output 2" promotes further confusion for Wizard users who already are not clear on the difference between OUT2 and OUTPUT2.

thanks, will do.
thought i was going to have a v5.24 RC out this evening but it will be tomorrow.

ok! turns out andrew made the improvements to the i/o reporting in the report.txt file and its in v5.24 rc4
here is the download link. www.centroidcnc.com/centroid_diy/downlo ... taller.zip
thanks in advance for your testing efforts, bug reporting, and suggestions.

[Boatwrights Workshop]

fyi.. CNC12 v5.24 RC4 (RC = release candidate = no beta count down timer) is available for testing.
http://www.centroidcnc.com/centroid_diy/downloads/centroid_cnc12_download/centroid_cnc12_v5.24_rc4_installer.zip

CNC12 v5.24 RC DRAFT release notes are here:
www.centroidcnc.com/centroid_diy/downlo ... _notes.pdf

For some apparent reason, the link doesn't work for me. When I click on it a window will flash but nothing happens.