I am loading tube racks with the autoload and then digesting the autoload step return values to see which tube barcodes are on the deck and at what positions. This works great when doing real runs, but obviously breaks in simulation.
I did this a while ago, but can’t remember if there is a built out library for this. I would like to fake the tube loading when running simulation, is there a library for generating step returns? Maybe there’s a better way?
I would not recommend trying to customize simulated step returns. I do not believe there is an existing library for this purpose, and it would be complex. That said, as long as you have sample tracking enabled then there are easy programmatic ways around this.
Linked below is a post that outlines various examples of barcode assignment and retrieval with minimal code changes needed to accommodate simulated runs.
@Stefan - the image URLs in the linked are from the old domain and I cannot edit the post due to its age. Would you mind restoring them if you have a quick second?
Dang, I am not using sample tracking turned on so I went with digesting the step return values. So my current iteration of code would not work with that.
Wondering if the cognex library might have this function in it, do you have a download of that library? I remember it can control the autoload and provide step return values as well.
Is there a reason you can’t enable sample tracking? If you are actively using barcodes, I would strongly recommend turning this on and exploring some of the functionality it supports, as it makes processing plate and sample data (especially barcodes) much easier.
The Autoload library the Cognex library wraps around primarily uses firmware commands which have a completely different return data return structure than the VENUS load single step. There are no features that support generation of custom return strings for simulation. To proceed with this strategy would require a function that would only be called in simulation, which would need to dynamically create the intended simulated return strings to be passed into whatever you are using to parse the step data strings at live runtime.
If you are open to enabling sample tracking and exploring a different option, you may find the original suggestion more straightforward, but it is completely up to you.
I believe I tried sample tracking but ran into issues due to how we build our decks and add tubes to our racks. We build our decks at run time and to further the issue I add tubes to racks based on step returns, to allow for any tube any position. I will have to double check how it interacts with our current tooling.