Functioning Fadal conversion from Gmoccapy to Probe Basic

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.image missing /media/kunena/emoticons/wink.png

-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.