Page 3 of 7
Re: CNC12 BETA v5.23 rev5 is now available for public testing
Posted: Wed Jan 22, 2025 6:48 pm
by 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.
Re: CNC12 BETA v5.23 rev5 is now available for public testing
Posted: Wed Jan 22, 2025 9:31 pm
by cnckeith
cncsnw wrote: ↑Wed Jan 22, 2025 6:48 pm
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.
Re: CNC12 BETA v5.23 rev5 is now available for public testing
Posted: Wed Jan 22, 2025 10:14 pm
by 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.
Re: CNC12 BETA v5.23 rev5 is now available for public testing
Posted: Thu Jan 23, 2025 4:33 pm
by cncsnw
cnckeith wrote: ↑Wed Jan 22, 2025 9:31 pm
... 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.
Re: CNC12 BETA v5.23 rev5 is now available for public testing
Posted: Thu Jan 23, 2025 4:36 pm
by cncsnw
Another note on v5.23 beta rev5:
The Utility menu text still says "... support is avalible".
Re: CNC12 BETA v5.23 rev5 is now available for public testing
Posted: Thu Jan 23, 2025 4:45 pm
by cnckeith
cncsnw wrote: ↑Thu Jan 23, 2025 4:36 pm
Another note on v5.23 beta rev5:
The Utility menu text still says "... support is avalible".
ah! we fixed that..its back
Re: CNC12 v5.24 will soon be available for testing.
Posted: Thu Jan 23, 2025 6:57 pm
by 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.
Re: CNC12 v5.24 will soon be available for testing.
Posted: Thu Jan 23, 2025 7:19 pm
by cnckeith
cncsnw wrote: ↑Thu Jan 23, 2025 6:57 pm
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.
Re: CNC12 v5.24 will soon be available for testing.
Posted: Fri Jan 24, 2025 4:02 pm
by cnckeith
cnckeith wrote: ↑Thu Jan 23, 2025 7:19 pm
cncsnw wrote: ↑Thu Jan 23, 2025 6:57 pm
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.
Re: CNC12 v5.24 RC4 is now available for testing
Posted: Fri Jan 24, 2025 4:45 pm
by Boatwrights Workshop
For some apparent reason, the link doesn't work for me. When I click on it a window will flash but nothing happens.
