trigger based on Position when using analog feedback

[BrianJahraus]

I am developing an application that uses two hydraulic cylinders to move a model in a pitching and plunging motion.

My hardware consists of a P4 computer running windows XP SP2. The motion controller is a PCI-7350, 2 axis board.

The two hydraulic cylinders are equipped with analog position sensors which provide the primary feedback signal for the motion control.

The drive signal from the motion controller is used to open or close a hydraulic valve, closing the loop. The motion portion works great.

I am using buffered contouring to generate a precise motion on the two axis using a vector space. The update rate is 10mSec and the motion appears to be correct. Is the contour update rate a precise 10mSec if the PID is running at 62.5 uSec?

My problem is I need to generate a trigger when the controller is on specific positions of the contour. I can't use breakpoints as I am using analog feedback instead of an encoder. I wrote an onboard program that monitors the contour buffer and toggles the breakpoint line when the controller is on or beyond the specific point. It runs ok and is close but, I am getting an occasional timing discrepency of roughly 16 mSecs. ie the trigger will occasionally be  late by more than 1 contour period.

I tried increasing the size of the buffer to hold all the points as I thought the delays might be occuring when the buffer was being updated. No change in performance. I tried assigning more time to the trigger program as it is the only on board program, but again it seemed to make no difference. I reduced host communications to a minimum, no change.

I have attached my entire application and a test sample waveform  in a zip file. You can run the application without any hydraulic cylinders if you set max following error to 32768. You should have a trigger pulse on the breakpoint line every 500 mSec.

Any pointers would be greatly appreciated.

[Jochen]

Brian,

1. Yes, you can reach exactly 10 mS update interval with a PID rate of 62,5 µSec. You can calculate the actual interval with the forumla provided here. Of course the accuracy is limited by the accuracy of the onboard oscillators of the board but this shouldn't be really relevant.
2. Generating triggers based on 2D position data is not a trivial task. I have tried to examine your program but it's a bit hard to read. I had a look at your onboard program. I don't understand exactly how you determine if the axes have reached a trigger position or not. It looks like you are only reading values from buffers. For an exact match with the physical positions you should read the real position values from the axes and compare them with your trigger position buffer. In your comparison algorithm you will need to add some tolerance to allow some deviation from the ideal trigger position (see image).

There are several possible solutions for your application. You could either try to implement the more advanced comparison in your onboard program but I'm not sure if this will result in the performance you need. The 7350 provides only a limited amount of CPU power for onboard programs. At last it all comes down to the question how good your deterministic real-time behavior needs to be. If some ms delay and jitter are ok for you then you probably could stick with this approach. If you need a better real-time behavior you should consider using either an additional real-time board like the PCI-7041/6040E that could run the 2D trigger algorithm or a PCI-7830R board that could run the algorithm on an FPGA.
There are even more options including the NI SoftMotion Development Module to design your own motion controller using LabVIEW RT but again, this depends on your application needs.

Best regards,

Jochen Klier
National Instruments Germany

Message Edited by Jochen on 09-09-2005 10:47 AM

[BrianJahraus]

Thanks for the reply.

I knew it would be hard to read, it's still in development and not well documented. The heart of the program is the do_countour profilewtrig VI.

The motion profile is loaded into buffer 2, The trigger point numbers in buffer 1. To trig on the 44th point, buffer 1 would have a value of 44. Pseudocode fo rthe oboard program is:

#start

if (trigbuffer not empty)

  TriggerPoint <= Next Trigger Point

#wait for Trigger

CurrentPoint <= (position buffer points done)

if current point <= Trigger point jump to Wait for trigger

else Toggle Breakpoint line

[BrianJahraus]

Thanks for the reply.

I knew it would be hard to read, it's still in development and not well documented. The heart of the program is the do_countour profilewtrig VI.

The motion profile is loaded into buffer 2, The trigger point numbers in buffer 1. To trig on the 44th point, buffer 1 would have a value of 44. Pseudocode fo rthe oboard program is:

#start

if (trigbuffer not empty)

   TriggerPoint <= Next Trigger Point

#wait for Trigger

CurrentPoint <= (position buffer points done)

if current point <= Trigger point jump to Wait for trigger

else Toggle Breakpoint line

[BrianJahraus]

Thanks for the reply.

I knew it would be hard to read, it's still in development and not well documented. The heart of the program is the do_countour profilewtrig VI.

The motion profile is loaded into buffer 2, The trigger point numbers in buffer 1. To trig on the 44th point, buffer 1 would have a value of 44. Pseudocode fo rthe oboard program is:

#start

if (trigbuffer not empty)

    TriggerPoint <= Next Trigger Point

#wait for Trigger

CurrentPoint <= (position buffer points done)

if current point <= Trigger point jump to Wait for trigger

else Toggle Breakpoint line

[BrianJahraus]

Thanks for the reply.

I knew it would be hard to read, it's still in development and not well documented. The heart of the program is the do_countour profilewtrig VI.

The motion profile is loaded into buffer 2, The trigger point numbers in buffer 1. To trig on the 44th point, buffer 1 would have a value of 44. Pseudocode fo rthe oboard program is:

#start

if (trigbuffer not empty)

 TriggerPoint <= Next Trigger Point

#wait for Trigger

CurrentPoint <= (position buffer points done)

if current point <= Trigger point jump to Wait for trigger

else Toggle Breakpoint line

[BrianJahraus]

Thanks for the reply.

I knew it would be hard to read, it's still in development and not well documented. The heart of the program is the do_countour profilewtrig VI.

The motion profile is loaded into buffer 2, The trigger point numbers in buffer 1. To trig on the 44th point, buffer 1 would have a value of 44. Pseudocode fo rthe oboard program is:

#start

if (trigbuffer not empty)

     TriggerPoint <= Next Trigger Point

#wait for Trigger

CurrentPoint <= (position buffer points done)

if current point <= Trigger point jump to Wait for trigger

else Toggle Breakpoint line

[BrianJahraus]

Oops, sorry for the other replies. Don't know what happened

Thanks for the reply.

I knew it would be hard to read, it's still in development and not well documented. I appreciate you trying to read it.

The heart of the program is the do_countour profilewtrig VI and the onboard trigger program.

The motion profile is loaded into buffer 2, the trigger point numbers in buffer 1. To trig on the 44th point, buffer 1 would have a value of 88 (2 axis * 44 points). When the profile is executing point 44 of the countour the prog should generate a trigger. Pseudocode for the onboard program is:

#start

if (trigbuffer not empty)

  TriggerPoint = Next Trigger Point                   // TriggerPoint is variable 1

  #wait for Trigger

  CurrentPoint = (position buffer points done)      // CurrentPoint is variable 4

  if current point <= Trigger point

      jump to Wait for trigger

  else

      Toggle Breakpoint line

      Jump start                                                // get next trig point from buffer

  endif

Else

End Prog                                                        // Trigger buffer is Empty

Essentialy I am trying to trigger on the current point being executed by the profile. This should be within 10 mSec and therefore, with the current cylinders and feedback, within 0.05 inches of desired position. Trying to trigger based on the position of the two axis will be very difficult when the two waveforms end up at different phases and amplitudes. 

Just explaining it to someone else highlighted a couple of bugs. The program waits till points done is greater than trigger. It should be equal or greater.

I also looked at the proile and it doesn't have the trigger points in exactly the right places. It is +- 1 position which equates to 10 msec.

I will fix these and try again. If this doesn't work I will try the position based trigger.

Thanks for the pointers.

Brian Jahraus 

[Jochen]

Ok, I understand. So you are not generating triggers based on the real positions but on the theoretical position. This approach is easier to program but it might have some flaws. Whenever there is a following error you won't generate the trigger at the correct position. Additionally there is the before mentioned jitter of your onboard program. Overall this doesn't sound like a very reliable solution but at last it's up to you to balance your application requirements with the efforts to meet them.
In my last answer I have tried to point out some reliable solutions to you but I kept it quite general as I don't know your needs good enough. Please provide some details about your real-time requirements so I will be able to give you a more tailored answer.

Jochen Klier
National Instruments Germany

[Jochen]

It looks like our last posts have coincided. So please post to the thread how things are going after you have fixed the bugs. Your real-time requirments don't look too tough so I feel quite confident that you should be able to meet them with your current approach as long as your following errors are limited to a reasonable amount.

Jochen