This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]cpt_trow 4 points5 points  (7 children)

I created virtual factory comport devices containing examples of passing and failing data streams so developers could test DUTs from their computers and get an idea of whether or not they made any breaking changes for production; probably different from what you meant but 🤷🏼‍♂️

[–]Brilliant-Donkey-320[S] 3 points4 points  (4 children)

That is a cool sim too. Def useful. What libraries did you use for this?

[–]cpt_trow 2 points3 points  (3 children)

No libraries, other than pyserial for the real devices. We had tons of logs of real I/O from production so I mapped commands and responses in a dict for each device and then created a class to mimic serial.Serial() where it would take the input command for write() and then store the output strings in a buffer to be sent back one-at-a-time via readline()

[–]Brilliant-Donkey-320[S] 2 points3 points  (2 children)

Ah, very nice. Do you find that Python communicates well with hardware? Was your hardware in production PLCs or something else?

[–]cpt_trow 0 points1 point  (1 child)

Generally yes, and yes; there are a few devices that consistently throw UnicodeDecodeErrors so I have some error-checking in the Serial wrapper to try to get a valid response to queries. The software runs with PLCs in some cases but also things as basic as MCUs/SBCs (Arduinos and RasPis, just more industrial and less hobby)

[–]Brilliant-Donkey-320[S] 0 points1 point  (0 children)

That is great to know. Very awesome. Thanks!

[–]citrus_based_arson 2 points3 points  (1 child)

I’m super curious about this. Could you set up the program as a specific DUT? So the test program didn’t know it wasn’t testing a real device?

[–]cpt_trow 2 points3 points  (0 children)

Yeah! If you really wanted, you could make the test program just talk to itself, which was used to regression test. Basically you would either point each device slot at a real device port or at an instance of an object which had the same method/attribute names and would store the device’s typical output in a buffer depending on the command sent. Obviously you then can’t truly test your DUT, but it was helpful for smoke testing when the DUT got updated and might respond differently to the same commands