Motion Control and Motor Drives

cancel
Showing results for 
Search instead for 
Did you mean: 

7344 onboard program latency

Dear experts, since four years we use a couple of PCI7344.
In our application we need to generate the exposure pulse for the camera to take images
at predefined positions. The higher the rate - the better.
For the moment we're limited by 7344 only, so no buffered breakpoints are possible.
Hence a simple loop is executed onboard to re-arm breakpoint, when it occurs.
With FlexMotion 5.20 and corresponding firmware the max. rate was about 200-250 FPS,
the BP was rearmed after about 4-5ms.
Here's the code:

void AcqAxis::LoadBreakpointSequence(float *Pos, int N)
{
//Sets breakpoint sequence and store the BP grab program.
u16 mask;
int label1=1;
int label2=2;
if(N>100) N=100;
if(N<=0) return;
i32 ActPos[120];
i32 NPos=N;
flex_load_var(BoardId,NPos,0x76); //store number of breakpoints in Var76 (save)
flex_load_var(BoardId,NPos,0x78); //store number of breakpoints in Var78 (index)
flex_load_var(BoardId,1,0x77); //store decrement=1 in Var77
for(u8 i=0;i
vars="" from="" 0x01="" up="" }="" mask="(0x01"><< Axis);
flex_begin_store(BoardId,1);
// Start the loop, index is in var 0x01 decrementing down to 0
flex_insert_program_label(BoardId,label1);
flex_load_pos_bp(BoardId,0x20+Axis,0,0xF8); //load indirect from the index Var78
flex_enable_breakpoint(BoardId,0x20+Axis,0x01); //arm breakpoint
flex_insert_program_label(BoardId,label2); //loop till bp is occured
flex_jump_label_on_condition(BoardId,0x20+Axis,NIMC_CONDITION_POSITION_BREAKPOINT,0,mask,NIMC_MATCH_ALL,label2);
//OK, BP is occured, decrementing index Var78 by Var77=1
flex_sub_vars(BoardId,0x78,0x77,0x78);
//Now if N=0 flag EQUALTO must be set... checking
flex_jump_label_on_condition(BoardId,0,NIMC_CONDITION_NOT_EQUAL,0,0,0,label1);
flex_set_breakpoint_momo(BoardId,0x20+Axis,0,mask,0xFF); //reset output
// flex_enable_breakpoint(BoardId,0x20+Axis,0x00); //disable breakpoint
flex_end_store(BoardId,1);

}

Now the problem happened: we've noticed, that very seldom the Axis2 (Y) encoder reading is suddenly
incremented by 32768 (15th bit flips somewhere?...). This leads to loss of reference of course,
and ruins the operation of our system.
In attemps to solve the problem we upgraded the FlexMotion to 6.1.2 and repeated the test.
The test is ongoing, so results I hope to report tomorrow, BUT!! The max rate of Breakpoints generation
DRASTICALLY decreased. The latency reached 20ms sometimes!
After reading carefully manual I've added following line to the onboard program:
flex_load_program_time_slice(BoardId,1,20,0xFF);

This improved situation a bit, at least within the time slice the reaction was again 4-5ms,
but rate couldn't be >50FPS, otherwise BP's outside the slice are missed.
Could you suggest the solution, which would cure both problems at the same time -
the 32768 jump and BP rearming latency?


W.B.R.
0 Kudos
Message 1 of 2
(3,015 Views)
The result of the test is positive. No 32768 jump is observed with FlexMotion 6.1.2.
So I desperately need an advice, how can we solve both problems...
Maybe some intermediate version? Or latest?

With best regards,
Igor E.Kreslo, PhD
Laboratory for High Energy Physics,
University of Bern.
0 Kudos
Message 2 of 2
(3,004 Views)