Using Multiple Promira Platform Handles in One System without Errors

---

Image by Mohamed Hassan

Question from the Customer:

I am using two Promira Serial Platforms to control the I2C and SPI devices in one system. I am also using the Promira LabVIEW Driver calling from TestStand. My issue - there are random intermittent errors as shown below:

• The error code 8030 is pushed up from LabVIEW to TestStand, and the only text shown is ps_queue_submit.
• I am leaving the handle open and passing the connection and the channel handle around. The error seems to occur randomly once out of every 100+ interactions.

So far, the only way I can clear the error is to close and re-open the connection to the Promira platform. Any insight into the cause of these errors would be appreciated.

Also, do you have recommendations for managing Promira platform handles when there is more than one Promira platform in the system? The two Promira platforms used in the system have different IP addresses. Both are using the LabVIEW driver and commands are sequenced with TestStand.

Response from Technical Support:

Thank you for your questions! We have two recommendations for your case that are based on potential causes of error, as well as a description of how the function ps_queue_submit operates.

Commands and Promira Platform Handles

The function ps_queue_submit sends out the accumulated commands on the I2C or SPI bus. This function performs the accumulated commands in the queue and shifts them in correct order to the subsystem (I2C, SPI or GPIO).

After the operation is completed, the queue is not auto-cleared. This allows the function to be called repeatedly if the same sequence of commands is to be shifted across the bus multiple times.

If any previous queue responses remain uncollected, the function returns PS_APP_PENDING_ASYNC_CMD, which indicates that asynchronous commands are still pending.

Uncollected responses can be recovered:

1. The queue_type tells what type of queue commands are executed. This function blocks and will return when the host receives the response for the first command in the queue.
2. The ps_collect_resp function can then be used to retrieve this first response and the remaining responses.

Note - if ps_queue_submit is called again before the previous responses are collected, then all uncollected responses of the previous queue will be discarded.

Are Promira Platform Handles Called Simultaneously?

The common root cause of random errors in multi-platform systems is unsynchronized access to a shared Promira platform handle across parallel execution threads. The runtime error 8030 suggests there is a race condition or timing issue in how the shared handle is accessed, especially when two Promira platforms are used simultaneously.

• When two LabVIEW threads or TestStand sequences concurrently submit commands to the same handle, the internal queue state can become inconsistent, resulting in a queue submission error.
• If two parallel LabVIEW threads or TestStand sequences try using the same Promira platform handle at the same time, the driver can throw a queue error. This occurs when the same handle reference is passed around without proper synchronization.

If that is the issue, we recommend adding a small delay, about 10–20 ms, between consecutive transactions on the same handle. That will allow the internal queue to

Are the Promira Platform Queues Processed Correctly?

If Promira platform handles are not being called simultaneously, here is a recommendation for working with queues:

• Create multiple queues and replenish them rapidly. As soon as a queue finishes, promptly resubmit to ensure there is always a pending queue on the Promira.

There is a significant latency between the PC and Promira platform, but the Promira platform can have multiple queues outstanding and will execute the queues autonomously.

Here is that gives an example of running that process. This sample script can stream at 20MHz without gaps. The error checking is not perfect in this script, but you should get the basic premise. NOTE – rename spi-nogap2.txt to spi-nogap2.py before using this script. Also, edit the script for the IP address of your Promira platform (line 41). This script can be further customized as needed.

We hope this answers your questions about errors and resolutions for Promira platform handles and queues. Additional resources that you may find helpful include the following:

• Promira Serial Platform System User Manual
• Promira Serial Platform I2C/SPI Active User Manual

If you want more information, feel free to contact us with your questions, or request a demo that applies to your application.