Max Frequency of Internal EIP IO Cards and TriggLIOs command

MikeEd

Has anybody previously pushed the Internal IO cards to a "high" frequency and noticed unstable behavior?


I'm wanting to generate a virtual encoder pulse to a 3D camera system along a linear but non-Cartesian aligned path (i.e, the linear vector has x,y and z components)

• This is on a Line profiler, not a snapshot unit

 
Others I've talked have prior setup a constant velocity motion path, and trigger frequency within the camera; I'd rather not take that approach as it is a bit iffy in many ways, and I think that is the route cause in may of the continual issues production issues on these prior systems.

The below seems, legit in terms of documentation, following the code, having the robot do moves offline; but I have my doubts if it will actually be that stable on a real machine. We can't really measure it and I'm guessing what will happen is we get these "random" glitches once running in a production environment.

1. The specification sheet ,mentions a output response delay of up to 0.5ms, which in theory means I could produce a 2kHz pulse output if I use both edges.
2. The only way I then to continually produce this train is a for/while loop containing a TriggLIOs command an array triggdata array that I continually cycle though across the inspection zone.

The sources I've error I'm concerned with is the jitter/buffering on the EIP network (Device net might have had change of state, but in EIP its really pseudo change of state still limited by the cyclic RPI)
The synchronization between TriggLIO. Surely it will be stable within TriggLIO's travel, but could get messy with start and end zones between each separate call. 

lemster68

Not any answers for you yet, but some questions.  Do you  have multitasking?  What about a timed interrupt?

MikeEd

Thanks Lemster

I've decided on the the approach, I'm going to test and push it, and we'll get what we get.  If I need more, then I can program a second delayed expose per trigger on the 3D Camera;  If that is still not enough, then we'll have to run the 3D cam as a straight imager to PC and add the sensor interface to recover the motion.  That last option thou just goes from a few hours to a few weeks work and another 10K equipment.

Yeah we have multitasking, but I'd imagine a timed interrupt would be worse??

I think since at the internal ABB level; you're then back to the main control cpu rather the just within the motion controller?  Plus a timed interrupt is also really just moving the timing function from the Smart 3D camera to the robot anyway. 


Thanks for the comment,  guess I'm trying to do some things that are a bit out there.