Switching buffers in contour mode

[Jochen]

Hi TulioB,

I had a look at your source code. As there are some function calls between the execution of each buffer in your double buffer example some amount of delay is expected compared to your single buffer example. Maybe some milliseconds get lost by your multithreading approach.
As your motion control board is a shared resource for both threads I don't see a real advantage of this approach compared to a straight forward approach like that (at least in terms of timing):

1. Configure buffer2
2. Configure buffer1
3. Start contoured move with buffer1
4. Reconfigure buffer2 to map it to the vector space
5. Wait for move complete
6. Start contoured move with buffer2
7. ...

Your approach is definitely more elegant but maybe you can save some time by choosing a simpler architecture.

In general host interaction is running with low priority on the 7344's µprocessor and it adds some amount of delay to motion applications. The only way to eliminate this delay is using blending (if possible) or single buffer contouring. For your application you will probably have to use single buffer contouring with breakpoint triggering which requires an encoder.

Jochen

[TulioB]

Hi Jochem,

I agree with you that it will be better to use single buffer, but as we discussed in a previous post, breakpoints don’t work in vector spaces. Do you know/imagine any other strategy to approach this problem?

Thanks!

[Jochen]

Alas! So it looks like we have closed the circle and reached the starting point of this discussion again.

As I don't know your application well enough here is some brainstorming. Please let me know if one of these ideas sounds appealing to you and I will explain it in a more elaborate way.

1. Use single buffer contouring and poll the vector space position either in your host program or in an onboard program. Check if you are within a target window for a tool change and set the digital outputs accordingly. Note: The onboard program can't poll the position much faster than a host program but it works independently from the host PC.
   
   
2. Use a counter board like the PCI-6602 to read the axes' positions in parallel to the motion board. You can route the encoder signals to the 6602 through a RTSI connection (no external cabling required). The advantage of this solution compared to 1.) is the much higher acquisition rate of the PCI-6602 (some µs compared to some ms with the 73xx). Thus you could react much faster.
   
   
3. Use an FPGA board like the PCI-7811R to generate the output signals. 1.) and 2.) are not deterministic due to the jitter caused by the operating system. This solution is deterministic with a timing resolution of 25 ns.
   You will need LabVIEW FPGA to program the 7811R. With LabVIEW FPGA and the NI-SoftMotion Development Module you even could replace the 73xx board and use an FPGA board as a motion controller which allows you to implement your own features.

Please don't misconceive this post as a sales promotion. I hope it gives you some ideas how to proceed.

Best regards,

Jochen
(btw: there is an "n" at the end of my name )

[TulioB]

Hi Jochen,

Options 2 and 3 are out of question. So if could explain better option 1 I would like to know more in terms of timing and pooling frequencies that I could expect.

I have done some very basic testing with a similar idea. Instead of pooling the vector space for position I do some thing like this:

-         configure a 2D axes vector space for contouring (single buffer for all the job)

-         configure a 1D axis vector space for contouring

-         do a start motion in both vector spaces at the same time

-         in the 2D vector space write axes position data

-         in the 1D vector space write a data that acts like a code defining an action

o       example: a value of 10 means turn on tool #1; 15 means turn off tool #1, 20 means turn on tool #2; 25 means a point where the motion could be pause, usually in sharp edges, and so on…

-         pool the for position the 1D vector space, check if the axis is stopped and the value is different from that last one pooled. If true, take the appropriate action.

This machine has a tool that is a pen to write text/numbers in the pieces, so that are many small moves to be done, then my concern with timing and pooling frequencies with this approach.

What about this strategy?
Thanks!

[Jochen]

Hi TulioB,

the more I think about this approach the better I like it. In fact this is a good way to map the vector space positions to the required actions.
Still my main concern is the jitter caused by the operating system and the asynchrnous communication with the board. You shouldn't expect a timing accuracy that's better than +/- 10 ms and on a non-deterministic OS like Windows there is always a chance for even bigger outliers.

If the general timing is ok for you but you see some sporadic outliers you could try to run this part of your code in an onboard program.

Jochen