01-24-2011 09:21 PM
Also, can you please tell me if there is any alternative method to extract
the encoder position and/or velocity from the motion card? Instead of
using a while loop to read the motor velocity via "Read Velocity.flx"
and output via "Load DAC.flx", can there be a way which I can
get the encoder position without passing to the software (the PC)?
The reason for this is that I do not want any phase delay introduced by the
potential PC processing delay or anything like that.
Great Thanks,
Ron Liou
01-26-2011 08:55 AM
Ron,
There is no way to route the encoder signal to an analog output signal through hardware only. This encoder is sending two (or three) digital pulse trains that are converted to position and velocity on your PC. In order to send them back out as an analog signal, this can only be done in software.
Like you stated before, your second axis seems to be disabled, or broken. Make sure you go through all of the configuration settings inside MAX to ensure you have your motion Axis enabled and configured to be a servo type, and that your analog output Axis is enabled and configured as a stepper type. Also, you may try starting with this example to make sure it is not your code that is causing the bad AO behavior. Good luck!
01-26-2011 09:42 PM
Hi Zach
If I use an on-board program (Begin Program Storage.flx) to read the encoder signal
and output to one of the analogue output. (Please see the attached VI) Will this still
introduce a phase delay?
Thanks for your suggestions although I have tried that example code and made sure
that the Axis configuration in MAX is correct. Is there anything else that could have
caused the problem?
Great Thanks,
Ron Liou
01-27-2011 02:03 PM
Hi Ron,
Anytime you take a signal from Hardware to Software and back again you will introduce a phase delay due to the latency involved.
01-30-2011 12:41 AM
Hi Joe,
I thought since this on-board program is stored in the flash memory of the motion card
and gets executed whenever the motion card is powered, the delay introduced by the
host computer due to the number of the processes the PC is currently handling does
not have any effect on this program.
In other words, no matter how many programs (motion control, DAQ, and etc)
I'm running on the host computer, the delay should be a constant value.
Am I correct?
As long as the delay is constant, it will be acceptable for my application.
Thank you for your reply,
Ron Liou
01-31-2011 06:10 PM
Hello Ron Liou,
If you are running an on-board program then your processing will be deterministic.
Lynn
01-31-2011 06:25 PM
Hi Lynn,
Sorry, what do you mean by deterministic?
Thanks,
Ron Liou
02-01-2011 09:42 AM
Hey Ron Liou,
By saying deterministic, I mean that its response time is constant for the same start conditions. So, we can say that the expected delay is constant.
Lynn
04-21-2011 01:01 AM
The problem is finally solved. After months of troubleshooting, it turned out being that the SH68-C68-S cable was faulty and because of the late response I received from NI, the warrenty of the cable had expired. As a result, we had to purchase a new cable. It was a horrible experience but at least, it's working now.