ADC Hal Component
14 Dec 2010 01:19 #6015
by brianm
ADC Hal Component was created by brianm
I have been playing around with making a EDM machine. One of things that I have to do is vary the feed rate based on the voltage on the part. I bought a Burr-Brown ADS574 ADC converter from newark. www.newark.com/texas-instruments/ads574j...hz-dip-28/dp/88K1031
I also have a mesa 5i20 board in the computer. I thought this would be fairly simple but I seam to be going in circles and was wondering if someone had some ideas or point me in the right direction.
The ADC converter is a 12 bit converter. My plan was to use 12 input lines on the mesa 5i20, make a hal component that reads the bits, convert it to a number and go from there. I am having difficulty getting the data from the chip. From what I can read of the data sheets on the chip. I am using a stand-alone operation where I lower a pin (R/C) for 25ns, then I have to wait for a status pin that goes from a low state to a high states (while the conversion takes place) and then back to a low state when the data is readable. I then should be able to get the data from the 12 lines and start the process over again.
I am new to programing with C and did not really understand how to handle the times, like the 25ns. So i tried to use a oneshot hal component. I tried to connect a output on my component to a one shot and set the width of the oneshot to like 100ns. then I wait until the status pin goes low (connected to my hal component) and read the data. I then send another "shot" to the oneshot component....
Anyhow, I seem to be going in circles now and am thinking someone has probably already done something similiar that I could just modify.
Thanks
Brian
I also have a mesa 5i20 board in the computer. I thought this would be fairly simple but I seam to be going in circles and was wondering if someone had some ideas or point me in the right direction.
The ADC converter is a 12 bit converter. My plan was to use 12 input lines on the mesa 5i20, make a hal component that reads the bits, convert it to a number and go from there. I am having difficulty getting the data from the chip. From what I can read of the data sheets on the chip. I am using a stand-alone operation where I lower a pin (R/C) for 25ns, then I have to wait for a status pin that goes from a low state to a high states (while the conversion takes place) and then back to a low state when the data is readable. I then should be able to get the data from the 12 lines and start the process over again.
I am new to programing with C and did not really understand how to handle the times, like the 25ns. So i tried to use a oneshot hal component. I tried to connect a output on my component to a one shot and set the width of the oneshot to like 100ns. then I wait until the status pin goes low (connected to my hal component) and read the data. I then send another "shot" to the oneshot component....
Anyhow, I seem to be going in circles now and am thinking someone has probably already done something similiar that I could just modify.
Thanks
Brian
Please Log in or Create an account to join the conversation.
14 Dec 2010 10:31 - 14 Dec 2010 10:32 #6020
by andypugh
Replied by andypugh on topic Re:ADC Hal Component
brianm wrote:
The reason I suggest a state machine is that such code always runs straight through and exits, which is important for a realtime component.
I assume you are using comp to write the component? linuxcnc.org/docs/html/hal_comp.html
This would be a simple state machine in comp syntax (this won't work, I am nowhere near an EMC machine to test it)
component adc "handle an ADC chip";
pin out bit start "chip adc start command bit";
pin in bit sync "chip sync bit";
param r unsigned state "state machine state";
function _;
::
FUNCTION(_){
static unsigned nanoseconds;
switch (state){
case 0: {
start = 1;
state = 2;
nanoseconds = 0
return;
}
case 2:
nanoseconds += period;
if (nanoseconds < 25) {
return; // wait a bit longer
}
start = 0;
state = 3; // drop through to state 3
case 3:
if (sync > 0) return ; // wait for synch to go back to low
{...
put the conversion code here
}
state = 0;
break;
default;
rtapi_print("That's not good, we shouldn't get to here");
}
}
The slightly oddly-named "weighted_sum" HAL component already does this part, if you want to save yourself some work.My plan was to use 12 input lines on the mesa 5i20, make a hal component that reads the bits,
You possibly need a state machine running in a fast thread to handle the timing.Anyhow, I seem to be going in circles now and am thinking someone has probably already done something similiar that I could just modify.
The reason I suggest a state machine is that such code always runs straight through and exits, which is important for a realtime component.
I assume you are using comp to write the component? linuxcnc.org/docs/html/hal_comp.html
This would be a simple state machine in comp syntax (this won't work, I am nowhere near an EMC machine to test it)
component adc "handle an ADC chip";
pin out bit start "chip adc start command bit";
pin in bit sync "chip sync bit";
param r unsigned state "state machine state";
function _;
::
FUNCTION(_){
static unsigned nanoseconds;
switch (state){
case 0: {
start = 1;
state = 2;
nanoseconds = 0
return;
}
case 2:
nanoseconds += period;
if (nanoseconds < 25) {
return; // wait a bit longer
}
start = 0;
state = 3; // drop through to state 3
case 3:
if (sync > 0) return ; // wait for synch to go back to low
{...
put the conversion code here
}
state = 0;
break;
default;
rtapi_print("That's not good, we shouldn't get to here");
}
}
Last edit: 14 Dec 2010 10:32 by andypugh.
Please Log in or Create an account to join the conversation.
14 Dec 2010 20:43 #6045
by brianm
Replied by brianm on topic Re:ADC Hal Component
That worked great. I had a couple of other problems with the way I connected the hal components, but basically took your code made it work and it is working great now. Thanks for the help. I have a question on the period variable.
I was reading the instructions for making a hal component and it says that the period is: is the time in nanoseconds of the last period to execute the comp
But I am having a hard time visualizing what that means. From the example in the code that you gave me it looks like it is just nanoseconds?
Thanks
Brian
I was reading the instructions for making a hal component and it says that the period is: is the time in nanoseconds of the last period to execute the comp
But I am having a hard time visualizing what that means. From the example in the code that you gave me it looks like it is just nanoseconds?
Thanks
Brian
Please Log in or Create an account to join the conversation.
14 Dec 2010 22:10 #6047
by andypugh
Replied by andypugh on topic Re:ADC Hal Component
brianm wrote:
Typically every function in the servo thread will run every 1000uS and the functions in the base thread about every 25uS (depending on the numbers you put in the iNI file). I reality that check that it has been at least 25nS since the function last ran is pointless, as it will be always several uS even for a very fast base thread.
Due to timing constraints and jitter the period will not be exactly 1mS or 25uS, the "period" variable tells the functions exactly how long it is since they last ran.
The actual execution times of the functions in a thread needs to be a lot less than the thread period.
There is a built-in variable called "period" which is the integer number of nanoseconds since the function last ran. There is also fperiod which is the same number as a floating-point value in seconds. However, you can't use any floating-point maths in a HAL function that is running in the fast (base) thread; all floating-point functions have to run in the slow (servo) thread.I was reading the instructions for making a hal component and it says that the period is: is the time in nanoseconds of the last period to execute the comp
But I am having a hard time visualizing what that means. From the example in the code that you gave me it looks like it is just nanoseconds?
Typically every function in the servo thread will run every 1000uS and the functions in the base thread about every 25uS (depending on the numbers you put in the iNI file). I reality that check that it has been at least 25nS since the function last ran is pointless, as it will be always several uS even for a very fast base thread.
Due to timing constraints and jitter the period will not be exactly 1mS or 25uS, the "period" variable tells the functions exactly how long it is since they last ran.
The actual execution times of the functions in a thread needs to be a lot less than the thread period.
Please Log in or Create an account to join the conversation.
Time to create page: 0.071 seconds