Good afternoon,
We're hitting that point in porgramming where it's not the logic but the structure that's giving us fits. We have a moderately complex vi that runs on a MyRIO, collecting data from three IMUs via I2c and writing the information out to a memory stick. However, the program collects at about 80Hz, and we need it much much faster.
i2c communicates at 400kHz, and going straight of the number of bits being transferred back and forth, we should be able to collect at around 500 Hz or so. So, there's something (if not a lot) in the program that is taking up valuable programming time.. I'm wondering if there is a way to do a time study on the program to identify where the significant slowdowns are, and if not, some guidance on what the likely culprits could be
Right now, some of my thoughts include:
- delays from writing data out via TDMS on the memory stick
- delays from using standard subvis for i2c. We have to read two separate i2c devices on the same bus, and right now we're doing this serially by calling on the i2c read twice, each time with the new slave id.
- delays from calculating a chart (which is dynamically generated)
- delays from misunderstanding the nature of the MXP connectors and thinking they run in a true parallel fashion.
- delays from using sequence/while/case structures to try and visually compress the program
- delays from using subvis instead of leaving the code in the main program
The program's a bit large and ungainly to post, but I thought this would be a good way to start to prioritize the investigation.
Thanks!