Oath

The Hobbs meter we're referencing is expected to be within 0.025% for accuracy, which I'm betting is a contributing factor (though maybe not a particularly large one). For this particular instance, we've only had the test machine running around 10-14 hours a day during weekdays, which would suggest a higher error rate. However, for what we are intending on using this data for, the actual drift per-shift is below the resolution we're using for the calculations anyhow (we only look at hours and tenth-hours currently), so the only way this would be an issue is if we ended up using it for long-term maintenance timing (1000 hour maintenances or something similar), but even that amount of imprecision might be doable. Since the RTC is pretty accurate, we might be able to just capture the RTC data on a machine start and stop and do math from that or something similar, if we need more precision. As for testing with accumulating TA timers, I'll give that a go! I hadn't thought to use that originally, so it might end up being a closer match to our current Hobbs meter. Thanks for your reply Joe!

I know this is an older post, but I have added a feature very similar to this as a Hobbs Meter to one of our scale programs, using an input to determine when a machine's run circuit is engaged. I'm curious though on how precise the second pulse is, as we've gained about 6 minutes a week from our reference Hobbs meter during testing. Is there any documentation on the overall precision of the second pulse, particularly for the V570? In all honesty, I suspect our reference Hobbs meter is probably running a touch slow, but I haven't had the patience or time to stand out at the machine with a stopwatch for a week to find out!

Jhav, Regarding ZK0's answer, we've been using the C# Communications Driver ( https://www.unitronicsplc.com/Download/SoftwareUtilities/unitronics_communication_driver_for_dot_net.pdf ) for most of our monitoring events. We basically poll the memory locations we're interested in about once every second (using the plc.ReadWrite() function) and make decisions or log data from these events. From our experience it can be a somewhat finicky connection, requiring a fair bit of robustness in the program (verifying returned array sizes, type-checking on receipt of your data, a way to handle a communication disconnect, etc), but you can actually end up polling the PLC very rapidly and discard any funky-looking data (for example, if it reads a value that might trigger an email alarm, have it check the next value to see if you're still in an alarm state to mitigate false-positive readings). Once you're collecting the data you're interested in, you can use MimeKit in C# to generate emails in varying formats, including maybe a logfile attachment, and then use MailKit to securely connect to an email service you have available to send a secure email. If you're interested in looking further into this solution, I do have a handful of wrapper functions to simplify my life of interacting with the PLC functions that does a lot of my checking for me on data reads - just let me know!

Thank you both for taking a look! @AlexUT I'd seen the Park-Miller RNG floating around (though I didn't realize it was in the examples!), but I wanted to be able to generate up-to 32-bits worth of data, (duh - the Parker-Miller does produce 32-bit) and the xorwow function looked pretty straight-forward to implement(plus I wanted to play around with the bit-shifting and XOR functions, which were very easy to use, which was nice). From a technical note, the Parker-Miller cycles after 232-1 uses while the xorwow cycles after 2192-232 uses (not that I need anywhere NEAR that many randomly generated numbers, mind!), so I was going for a more robust system, where you might be generating multiple times a cycle, for a really long time (though both PRNG's are likely overkill in most cases). The thing I found most interesting about the xorwow, though, is that by increasing or decreasing the number of states, you can increase or decrease your cycle time, respectively, as the states shifting like they do mimics a really big bit-shift. I'll have to more carefully peruse the example files though - there is certainly a lot of things there!

I'm in the process of learning PLC programming, specifically in using the .NET Communications Driver to collect live-data from Vision PLCs (among other various tasks), and was wanting a way to generate some random data on the PLC for dynamic testing. What I found was a lack of a built-in random functions! So, for both the fun and functionality, I decided to implement a Shift-Register Generator for producing 32-bit Double-Word Pseudo-Random numbers (what a mouthful) based on the xorwow generator ( https://en.wikipedia.org/wiki/Xorshift#:~:text=four%20words%20*/%0Auint32_t-,xorwow,-(struct%20xorwow_state ). The project is implemented on a V570 (as it was what we had easily at-hand), but the underlying ladder logic should be easily portable to any similar hardware, so long as there are 10 DW's available for storage and output. An example of collecting just an integer value from the double word is also included. As I am still learning, please don't hesitate to point out suggestions or corrections within the program itself, in either style or implementation. Thanks! RandGen.vlp