Industry 4.0, IioT, MQTT, OPC UA
Open discussion on Industry 4.0, IioT, and MQTT
Subforums
-
- 8
- posts
-
- 18
- posts
2 topics in this forum
-
- 33 replies
- 2.8k views
-
- 1 reply
- 315 views
-
Member Statistics
5,905
Total Members501
Most Online
-
Topics
-
-
Who's Online (See full list)
-
Posts
-
Out of curiosity I worked on this a bit. The attached vlp is nowhere near perfect, it was just banged together to show the concept I was talking about. I'd be putting in various other compares to limit the flash rates, both min and max Hz. Along the way I changed my thinking a little, this works on a simple method of using scan rate, but this basis could easily be changed to something else more "fixed". It was done on a 130, but should transfer to anything else with a bit of minor tweaking. It flashes the screen backlighting impersonating an indicator. This might need changing for your model. Look through the ladder and it should all become apparent as I haven't refined it at all. (and I'm not going to!) 🙂 cheers, Aus B130timerflash2.vlp -
Interesting this came up again. A little while ago I had to do something away from my normal methods of conversion, and thus had some converting to do. The formula that works that converts the raw UTC correctly is: =(A1/86400)+DATE(1900,1,1) with the result then formatted as dd/mm/yyyy hh:mm:ss where A1 is the raw UTC. cheers, Aus
-
I wrote a VBA function in Excel to do the conversion, but generally just us the following formula in Excel. Date = {UTC}/24/60/60+2. I make the date to be off 2 whole days from Excel's calculation in Windows (different if you are using the base 1/1/1904 Macintosh version of Excel). One of those days is because 1900 is not a leap year, but Excel erroneously thinks 2/29/1900 is a real day (which it is not). Unitronics get the math correct on this front. I think the second day comes from the fact that Excel seems to start the dates at 1/0/1900 not the first of January (one base math not zero base math). -
Has anyone experienced this? Sometimes when engaged in a lengthy cache download from a (in this case) V1210 PLC the PLC will crash with this error: The cache download is over the internet and the issue may be a flaky internet connection, but it certainly should't crash the PLC. -
It looks to me like you're being killed by SB 7 in the first ladder rung (Modbus subroutine). If the entire sequence doesn't complete in 100ms then you restart it with the SB 7 pulse. Why not do away with that rung and restart the sequence by Setting MB 3 in rung 7 instead of Resetting MB 24? If that specific logic is important for some reason I'm unaware of, try using SB 3 (or better, direct contact of SB 13 [you should also be using SB 15 instead of SB 7 in your current configuration]), or best, time the entire sequence and replace SB 7 with a self-resetting timer that has plenty of time for the entire sequence.
-
-
Blog Entries
-
