Passing a speed value to an interface card

More
11 Mar 2012 13:44 #18528 by btvpimill
Looking for some suggestions/advice/help here. I have been working on a custom interface card and need to pass a speed value to it. In this version, I have 3 pins on the PP available to use. In normal operation they are:
flood on/off => output from LinuxCNC
spindle on/off => output from LinuxCNC
Estop <= Input to LinuxCNC

I was thinking about calling a custom M1xx code to do this:
Pass value from part file to Mcode
re-purpose the Estop as an acknowledge input
use flood as 1 bit data and spindle as clock
clock out the "value" for the speed, waiting for an ACK between each bit

when done, fix Estop back to Estop function
Return from Mcode.

I can do most of this, but I have a few questions. (imagine!!!)
1) how would I shift the value to determine flood bit value?
2) how do I "wait" for the ACK before clocking the next bit?
3) Better ideas are MOST welcome!!

I do not have to have the built in spindle function working, but it would be a plus. Basically I want to be able to transmit a speed, then turn it on and off back in the main program.

Please Log in or Create an account to join the conversation.

More
11 Mar 2012 16:00 #18530 by btvpimill
Ok, After reading around in here some more, looks like there are some really cool ways to do this. re-mapping being highest on the cool list.
But I think for now, I will use m64/65 along with m66 for the ack.

So the new question is this: is there a way to pass a value 0-100 or 0-255, doesn't matter, to my already existing tool change Ocode, then convert that to my bit banging? Now I know I can pass a value, and I realize this way does not allow me to play with the spindle overide, but that is fine. I have been running CNC machine for 15 years now, and I can count on 1 hand the number of times I needed to adjust the speed during a cut. Mind you I do play with the feed to get it right at times.

I read something about select8. Is this the direction I should look?

Please Log in or Create an account to join the conversation.

More
22 Apr 2012 19:03 #19436 by btvpimill
I'm back again with this same issue. Is there an easy way ( meaning not using comp) to get the 8 bits of a byte to send out? The easiest way for me is to call either an m1xx or an O<sub> to send the speed changes.

I would like to for now just do this in g-code with m64/65, but short of running a loop the number of times to equal the speed, I am lost. Seems rather silly if the speed is 250, to run a loop 250 times when I should be able to loop 8 times.

Help anyone??

Please Log in or Create an account to join the conversation.

More
22 Apr 2012 20:46 #19439 by andypugh
btvpimill wrote:

I'm back again with this same issue. Is there an easy way ( meaning not using comp) to get the 8 bits of a byte to send out?


I thought there was a component for that, but I didn't find it just now looking at the components listed near the bottom of linuxcnc.org/docview/html/
The inverse exists (though it is called "weighted sum" rather than what one might expect).

I can see an argument for the conv32_bit component having an option of having more that 1 bit output

Is there a good reason not to use a PWM? It wastes a lot fewer pins.

Please Log in or Create an account to join the conversation.

More
22 Apr 2012 20:59 #19440 by btvpimill
Most likely not so much a good reason as a here I am reason. My spindle is a R/C speed controller. I know I saw something on here some time ago about directly controlling it from LinuxCNC, but of course can't find it now.

So as you may be aware, R/C signals are not just simple PWM as such. While they can be closer then 20mS between pulses, typically they are not. This is why the complicated solution to a simple problem. As it is now, I can turn the spindle on and off, but of course the on speed is hard coded.

If you remember back, I was working on a control card that would talk to LinuxCNC instead of just bit-banging, I still want to acheive this. But time is pressing and I need to finish this before I am allowed to complete that effort.

Please Log in or Create an account to join the conversation.

More
22 Apr 2012 21:07 #19441 by btvpimill
Also didn't want to spend uP cycles counting PWM signals constantly

Please Log in or Create an account to join the conversation.

More
22 Apr 2012 21:21 #19442 by btvpimill
Here is what I was thinking:

Main program has this:
O<speed.ngc> P200 call // This is supposed to call a sub called speed and pass it a value in this case 200

then speed.ngc would look like this:

while #1
M65 paraport.0.pin14 true // I am not at all sure of the correct format here
M66 paraport.0.pin15 true // Same delima about format
M65 paraport.0.pin 14 false
M66 again // Of course this is all just some VERY basic hand shaking.
#1 = #1 - 1
while end

endsub

I think this whole thing is wrong, but it gets my idea across. Does it make sense and where can I find the correct format for the M64/65/66? I have read what I can find about them, but the Docs simply seem to say they operate on dig 0-4. well what is dig 0-4? where is it defined and how do I assign them to PP pins?

Please Log in or Create an account to join the conversation.

More
22 Apr 2012 21:28 #19443 by andypugh
btvpimill wrote:

I have read what I can find about them, but the Docs simply seem to say they operate on dig 0-4. well what is dig 0-4? where is it defined and how do I assign them to PP pins?


Yes, the docs leave out a really important bit of information. It is actually hidden here:
linuxcnc.org/docview/html/man/man9/motion.9.html#PINS

M62-M65 change the value of the motion.digital-out-NN pins in HAL.

So, you net those pins to parport pins in HAL

Please Log in or Create an account to join the conversation.

More
22 Apr 2012 21:40 #19444 by btvpimill
MANY MANY thanks Andy!!! I will go play with this and see if I can get it to work for me.

Please Log in or Create an account to join the conversation.

More
23 Apr 2012 18:11 #19467 by btvpimill
Well this was working really well, right up untill I figured out M66 doesn't seem to work in sub's for <2.5 version.

Off to learn (in a hurry) about sending PWM out

Please Log in or Create an account to join the conversation.

Time to create page: 0.131 seconds
Powered by Kunena Forum