Motion Control and Motor Drives

cancel
Showing results for 
Search instead for 
Did you mean: 

Avoid "double" breakpoint occurence

Hi there, First post so apologies if missing out on any conventions.

 

I am setting up a vision inspection system with two stages in xy-configuration controlled by PCI-7350. The samples are located in a grid, which can be slightly irregular due to placing inaccuracy. Previously we stopped for image taking, but now we are switching to using breakpoints to take images "on the fly".

 

In principle, I have got this working with a buffered array of breakpoints (on x-axis) and using arrays for movements that are blended. However, occasionally it happens that images get lost when switching between two rows as two breakpoints are triggered almost simultaneously. How can this be avoided? I have tried changing the "Requested Interval (10 ms)" input on the "configure buffer.VI", but that did not help.

 

Could I change the deadband or something like this on the stages? Or do I need to rewrite breakpoint positions to the buffer for every new row? Any suggestions would be most welcome.

 

A second question (perhaps worthy of it's own thread) would be how to handle the movement more efficiently. The image processing will require a lot of processor resources, so I would like to take care of the movement on board. I have tried a little with buffered contouring, but with little success. I have also seen examples on onboard programming, but not yet given that a go. Which way would the experienced user suggest me to go?

 

Thanks in advance for your helpful input.

 

/Anders

0 Kudos
Message 1 of 6
(3,716 Views)
Hi Anders,

if I understand you correctly, you are blending the movement between samples on the x-axis (with the breakpoint list) and the "next row" y-axis movements. When the blending starts too early after the last breakpoint has been passed, you may run into the breakpoint being triggered again while moving in y-axis. Therefore, my primary recommendation would be to increase the path widths a bit thereby creating a "safe area" after the last breakpoint, in which y-axis movements will not cause a breakpoint trigger. Any other propositions would require a small sketch of how your breakpoints are arranged around the blended moves.

To also respond to your second question: onboard programming is useful for condition monitoring or simple stand-alone programs that react on trigger events - but the performance gain intended by taking off load of the PCs CPU is minimal on modern PCs, as the main calculatory functions (trajectory, blending, ...) are done on the motion controller's DSP regardless of wether you run the program on-line or on-board...

The best approach therefore will be to implement a multi-loop architecture in LabVIEW to efficiently use all available cores. To improve loop speeds, techniques like pipelining can be used to enhance parallelization even more...

Best regards,
Sebastian
0 Kudos
Message 2 of 6
(3,690 Views)

Hi,

 

Thanks for your advice SFK.

 

 

I now have a safe zone, which helps, but now I ran into a different problem; For some reason my breakpoints do not always occur.

 

I have attached  the VI (apologies for mess) and some plots for understanding the problem. In this VI I want to blend two axis movement and write breakpoints to a buffer in between every row. It is sort of puzzled together from two different examples; Sequence of Blended Vector Moves.vi and Buffered Contouring (Rose).vi

 

Going through the letters to help understanding the purposes of the steps:

 

A - load breakpoints is an array of the number of breakpoints I want to load for every row. Every other item is a 0 as I move between rows. When I define the buffer sizes I used either the sum of all breakpoints to be loaded or the max number for one row (not visible here). My svanning grid is 12 rows with 10 columns, so 10 is the maximum of points.

 

B - Old Data Stop (True) is set to false as I otherwise run into an error with old data, i.e. some points have not been triggered. This is the problem I need to avoid.

 

C - A VI that takes the stage to the starting position, which is a now defined 1mm to the left of the starting point. The start and the endpoint of each rows is 7mm outside of the breakpoint positions (spaced by 7 positions, so the safe zone should be there.

 

D - Here is where the breakpoints are loaded in case the number is >0. The array with remaining breakpoints is passed. The position where the breakpoints are loaded is added to the plot of the stage movement.

 

E - Adds where the breakpoints occurs to the plot.

 

In the attached plots my problem can be seen. The movement starts low left. What is also very puzzling to me is why this pattern looks different depending on how I define the buffersize.

 

Any help is greatly appreciated.

 

Thanks,

anders

0 Kudos
Message 3 of 6
(3,667 Views)
attached VI twice and not the intended image, which is here.
0 Kudos
Message 4 of 6
(3,666 Views)

Hi again,

first issue I am seeing: the "Add Array Elements" function you are using in the circled Diagram Disable Structure "A" will not return the element count of the connected array, but the sum of it's numeric elements. E.g. a numeric array containing the elements 2, 4, 6, 8, 10 will return a sum of 30, not the count "5" that you would expect. To measure the length of an array, use the "Array Size" function located in the Programming » Array palette.

Secondly, the purpose of your code "D" remains unclear to me - I would expect the breakpoint count to be constant for each row, adjusting only maybe the values itself for an offset. Therefore, the use of the "Split Array" function in combination with the autoindexed breakpoint value seems totally out of sense (excuse me for being so drastic). Normal use of the breakpoints would be to load the complete list of breakpoints for one row into the buffer, let the table move and re-load the buffers for the next row when in the new safe zone.

To be honest, I believe the card is doing exactly what you have programmed Smiley Wink

 

My recommendation would to completely rip the breakpoint management from your code, test the remainders for function of the movement/positioning and re-insert a simplified breakpoint handling code.´

 

Best regards,

Sebastian

0 Kudos
Message 5 of 6
(3,635 Views)

Hi Sebastian,

 

Thanks for your efforts here. However, I think my explanation lacked a few details which lead to a some misunderstandings from your side. 

 

As you say, the code in A either takes the sum of all breakpoints to be loaded (I want it to work that way) or I take the max out of the array (which is 10). Depending on which one I  use, I get different breakpoint behaviour as can be seen in the two plots.

 

I understand that section D is unclear, it is written so because we normally inspect round wafers -> number of breakpoints  varies between rows.

 

The card is probably doing what I am telling it to do, I would estimate the probability of that to about 100%, even though I guess most of us always are sure there is a machine error, not a coding error until proven wrong (also close to 100% of the times)

 

Also all movement works very well as can be seen in the graphs, and the brekpoints load when they should.

 

Somehow it is the way the buffer size and the number of points are defined that leads to this peculiar behaviour. If I load them all at once, they all occur, but then I get a double triggering as I described in my first post. The reason is that we calculate the rotation/translation of the array and feed those points, so a slight rotation of the sample leads to two breakpoints just after each other.

 

Hope that this described it better and that someone could  help meunderstand how to configure the buffer.

 

 

Regards,

Anders

0 Kudos
Message 6 of 6
(3,627 Views)