Functioning Fadal conversion from Gmoccapy to Probe Basic

Doesn't the widget just pull from the CAROUSEL component after it is referenced? Shouldn't the turret widget just track carousel.N.homing and carousel.N.homed?

When you say copy that over, do you mean into the carousel.comp file?

@tommylight you can permanently delete, hit delete while trying to hit edit, so just started the post over.. /o\

i have not dug into the carousel comp, but the dynatc items in straight macro driven atc is just in the Mxx macros in sections that are commanding carousel movement and that is how the widget is synchronized to the machine movement commands  if you want to post up your atc macros we could look at them.  wouldn't be a bad thing to add them to a fadal conversion file in probe basic.

The carousel component is really nice. I don't see too many ATC setups if any that will not work with carousel component. What element do i need to tie my "carousel.0.homed" to? You should consider including pins to allow user to tie the carousel component pins to your widget turret.

Also, Gmoccapy has "analog-enable" pins to tie to physical overrides. It makes override setup very easy. Example below

setp     gmoccapy.rapid.rapid-override.analog-enable 1
net      rapid-override-gmoc      gmoccapy.rapid.rapid-override.direct-value    <=    rapid.override-output

COlger81 wrote:

When you say copy that over, do you mean into the carousel.comp file?

Sorry, that was a useless & horribly cryptic response earlier... I hate getting those sort of responses myself.  Mea culpa.

I had a really long & detailed answer for you typed up, but I think it's unnecessary and likely will lead to confusion.  I'll do the shorter version.

• PB does not use carousel.comp to do anything.
• Instead, PB uses macros (xxx.ngc files) to:
  • Calculate direction and how far to move the carousel platter
  • Keep track of which tool is in which pocket (or spindle)
  • Update & move the on-screen ATC widget so it matches reality
  • Perform all the other ATC-related functions (move head up/down, activate drawbar, orient spindle, etc.)
  • Write persistent data to the linuxcnc.vars file so PB & LCNC can figure out what tool is where on re-start

This means you've got three options as far as controlling the ATC:

1. Stick with the 'stock' PB macros:
   • Abandon your existing carousel.comp scheme
   • Edit the PB macros to fit your hardware
2. Use carousel.comp and heavily edit (or write new) the PB macros so that:
   • Carousel.comp controls the physical movement and reports the various states to the modified PB macros
   • PB macros still keep track of which tool is in which pocket
   • The ATC screen widget reflects reality (because there's no other way to know which tool is in what pocket)
3. Something else super-clever but unknown to me

The PB ATC control scheme was written for geneva-wheel, DC (or AC) motor carousel hardware using relays to turn the motor FWD/REV.  It was not specifically written to control any other hardware arrangement and the scheme requires some significant adaptation to work with or non-geneva wheel hardware.

As luck would have it, your Fadal has (if the 6030 I was climbing on last night is similar) a geneva wheel driven by a 3P AC motor controlled with two (reversing) contactors.

My advice is to stick with option #1 as you're in a square peg, square hole situation with the PB control scheme.

If I'm wrong about your Fadal's hardware (i.e. side-wheel or a position-mode servo driving the platter), you'll need to do option #2 or #3.

So...assuming you chose option #1...  you do NOT need to copy the (DEBUG...) stuff I pasted earlier anywhere.  That (DEBUG....) ;thing is the way the PB .ngc files 'talk' to the on-screen ATC widget to make it animate.  Look through all the PB toolchange macros and you'll see them scattered around; every time the PB macros move the physical carousel, it's followed by one of those (DEBUG...) statements so the animation does its thing.

Don't forget about those statements, however.  They're dead useful during testing if the screen dingus isn't matching the real ATC.  You can paste those (DEBUG...) things in the MDI field and run them like g-code and they'll cause the screen animation to happen.

I'm not a PB dev, LCNC dev, or anyone else clever.  I hate computers and I hate software even more... but I'm persistent (and I want a working ATC) so I've been trying to unravel those bits of LCNC and PB and QtPyVCP that get in my way for some time.  Maybe my aggravation can aid in some small way.

I'm quite sure this will lead to more questions... have at it and I'll try to help.  I promise my advice is worth at least 4x what you paid for it.

-Ralph

COlger81 wrote:

Also, Gmoccapy has "analog-enable" pins to tie to physical overrides. It makes override setup very easy. 

PB also has same-function pins, but your customconfig.yml file needs to have the following in it under data_plugins:

Once that's in the .yml file, you can open halshow and see that there are some new pins available under qtpyvcp, like:
qtpyvcp.spindle-encoder-rpm
qtpyvcp.spindle-load-indicator
qtpyvcp.feed-override
qtpyvcp.spindle-override

And some others.  

If you use an analog pot, you can set up the analog-in and scale stuff in your normal hal files, but the 'final' connection to the qtpyvcp.xxx-override pin needs to be in the postgui.hal.  Same-same for encoders used as override knobs.

this is from the sim for M13 which is home carousel subroutine:

o<m13> sub

; Move tool carousel CW until ATC zero
; Parameter #5170 is used to track the current tool pocket (persistently)
(print, o<M13> P#<p>)

(DEBUG, EVAL[vcp.getWidget{"dynatc"}.atc_message{"REFERENCING"}])

M64 P3 ; Move Motor FWD
M66 P3 L1 Q20
O120 if [#5399 LT 0]
    (abort, failed to home carousel)
    M65 P3; stop motor
O120 endif
#5170 = 1
M65 P3 ; Stop motor
#5171 = 1

(DEBUG, EVAL[vcp.getWidget{"dynatc"}.atc_message{}])

#1 = 0
o130 while [#1 LT 12]
    #1 = [#1+1]
    #2 = #[5190+#1]
    (DEBUG, EVAL[vcp.getWidget{"dynatc"}.store_tool{#1, #2}])
o130 endwhile

M61 Q#5231 G43 H#5231 #5210 = 0

o<m13> endsub [1]

M2



I don't know your config or atc setup so no idea where it would go.  these commands are found throughout all of the subroutines and for it to function you will need to place them in the same/similar places in your macros or carousel component.  it has a been a very long time since I was playing with the atc stuff with Turboss and I do not remember if the carousel will only work if it references to the home #1 pocket position to start the initial synchronization or if a different method that requires no motion and may leave the platter indexed to a pocket that is not pocket #1 will also work.

Lcvette

I can sort through the macros if needed but by chance do you have a list of the ATC widget commands? I'm not great with qtpyvcp yet. I have managed to sync the widget turret reference and tool # with my actual turret, slowly getting there.

Thank You