UniOPC
UniOPC Server (Unitronics OPC Server) enables you to read and write data between Unitronics OPLCs and applications that support OPC, such as SCADA programs.
66 topics in this forum
-
- 0 replies
- 449 views
-
- 5 replies
- 181 views
-
- 0 replies
- 468 views
-
- 0 replies
- 750 views
-
- 2 replies
- 1.4k views
-
- 4 replies
- 2.4k views
-
- 0 replies
- 643 views
-
- 2 replies
- 1.1k views
-
- 0 replies
- 432 views
-
- 1 reply
- 1.7k views
-
- 1 reply
- 991 views
-
- 2 replies
- 917 views
-
- 0 replies
- 822 views
-
- 1 reply
- 1.5k views
-
- 10 replies
- 2.6k views
-
- 4 replies
- 13k views
-
- 0 replies
- 1.5k views
-
- 1 reply
- 2k views
-
- 3 replies
- 1.8k views
-
- 3 replies
- 1.3k views
-
- 2 replies
- 2.2k views
-
- 2 replies
- 2.3k views
-
- 0 replies
- 1.1k views
-
- 0 replies
- 3k views
-
- 1 reply
- 1.4k views
-
Member Statistics
7,631
Total Members1,206
Most Online
-
Topics
-
-
Who's Online (See full list)
- There are no registered users currently online
-
Posts
-
I also suggest that you take a look at deriving your time by using a 1.25 or 2.5mS Interrupt Routine. Bearing in mind all of Joe's comments, using the Interrupt might give you better accuracy. In some ways it is likely easier to implement, too. Look up Interrupt in the Help index, and then go to Interrupt Routines. You could easily implement both measures concurrently to let the PLC show it's own comparisons over a week or so. I suspect that you will find the Interrupt will be better accuracy, but it would be interesting to know the result. cheers, Aus -
By Fernando Castro · Posted
whatever SCADA software you want.... the more appropriated question is what SCADA software your client can afford? If your client only needs visualization, it may not need to be necessarily a SCADA software. I implemented a visualization system using this stack: Grafana, Influx DB, Telegraf to monitor an entire facility. Everything open sourced. -
By Fernando Castro · Posted
I just started playing around PID with Unitronics and also, I cannot test the program on the actual process yet. Having said that to test the logic what I did was a custom sub routine that will simulate an input based on the output, of course this will never maintain a setpoint but at least I can see the PID in action trying to maintain the given set point and test the logic for enabling/disabling the PID and starting the autotune. The program is as follows. I linearized a the PID output to a series of increments from -50 to 200 then each second, I add the increment value to the input and just with that you can see some oscillations. -
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! -
By Joe Tauser · Posted
I'd reach out to support@unitronics.com for this one. I'm pretty sure the the one second pulse isn't running off a crystal oscillator. Neither is the real time clock. I tell people that the RTC can drift one minute per month. What is the accuracy of the Hobbs meter? You could be running into a cumulative scan time issue. The scan time of a V570 is typically 5 - 10 ms, and if you're accumulating seconds based on the the one second pulse during the scan you could be off by some amount for each count. If the time accumulator is running for a whole week then you're talking about 604,800 seconds. Six minutes is 360 seconds, so the error is 0.06%. Over a year you could be off by five hours. Does that error matter? I would try an experiment using accumulating TA timers, which are tied to the internal clock and run independently of the scan. Use whatever logic you have enabling the one second pulse and run a 1 hour TA timer. When it times out increment a register to count hours and reset it. At the end of the week you can look at the hour count register and whatever the current value of the TA accumulator is to compare to your Hobbs value. Joe T.
-
-
Blog Entries
-
