I’m using a barcode scanner in serial device output mode to simulate specific torque analyzer output so I can test my app logic around upper and lower test limits, rounding, and reformatting to display trailing zeroes. Ultimately the torque analyzers will be connected in the same way, and when a test is performed they will output via serial connection, albeit with slightly different connection parameters (which the app sets based on a single select drop-down list).
This exercise has left me with some questions which may or may not be product suggestions.
I’m wondering if I can use the output from this “List Ports” action to dynamically populate a drop-down list (or a table so I can use an interactive table widget) to allow selection of the desired COM port. I’m currently doing this using a static list.
I’m also wondering if there is a way to get Tulip to confirm that the connection was successful, indicate which device is actually connected to Player, etc. Of course we could do a test on the analyzer to confirm device output, but since this is a GxP application we don’t get to do “practice runs” with product for release, so we would need to have an extra set of “Not for Human Use” devices on hand to do those connectivity trials.
I did review this post and it partly answers one of my questions, I need to try connecting a bunch of the devices (Mountz EZTorQ III various models and my TEEMI T26N-AU barcode scanner to make sure I can differentiate between them.
Assuming your remaining question is on addressing many devices like this, you’ll want to use a variable input in the “Identifier” portion of your “Send” command.
Similarly, when you make the “Connect” command (that runs when the app opens, the process begins, or whatever) you’ll want to have some kind of logic that names these different connections in a readable way - likely the easiest is to search by PID/VID in your ARRAY_INDEX_OF() function. Note that you won’t be able to programmatically message to devices on other stations; those you’ll need to explicitly state what station to send messages from in the “At This Station” drop-down.
Ah! Sorry I missed that.
At the moment, we are not able to have Trigger logic act upon whatever the result of this connection attempt is. However, some notes:
You could probably make some more-complex logic to do so, by leveraging the “Stop Remaining Triggers on Error” feature. For example, after connecting attempt to send a blank message to the device. Then, have a subsequent trigger in series that would go to a next step - with “Stop Remaining” enabled, I would expect this to not happen until there were no more errors. (Not positive if this would work, but worth a try )
Most, but not all, connection failures will be reported as an Error message in Player for the user to view and potentially act upon.
The Serial (Player Only driver actually does a pretty good job of reporting its status and potential errors in the Developer Console, though I suppose this is more important for debugging.