MrPLC Member
  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About k0d3

  • Rank
    Hi, I am New!

Profile Information

  • Country United States
  1. I was under the impression that the Rockwell clock update was only applicable to controllogix PLCs. I'll look into it for micrologix. Thank you.
  2. I greatly appreciate the help. I'm going to work on it and I'll update the post with the final solution. But I rather do like using my HMIs to handle the network side of things. Thank you again.
  3. Thanks for the reply Joe. I actually utilize some Graphite G07s and can easily pass it through the HMI gateway. I am definitely not solid with Redlions and I'm not sure how to go about pulling the direct RTC:0 word into the HMI for the distribution using the standard Allen Bradley driver. I suppose I could use a CPW function and populate a holding register of sorts then using that push it out and use another CPW in each connected PLC to push it back into their RTC file. Would you happen to know if the RTC is viewed as a Long Integer or what data format would work best?
  4. Good day everyone, First post here so hopefully I'm not violating community guidelines in anyway. I've got a system that has some 50 odd Micrologix 1100 and 1400 in use and I'm currently working on setting up an auto timesync for all of them using just 1 of the PLCs that will be my master time PLC. So far I've put together the logic for all the message instructions with the corresponding IP of the slave devices. I'm running. Into an issue with not being able to terminate/break the message connection on a PLC that I have already synced. Is this even possible to do on the ML1100. Once I get to 16-17 messages DN it starts to ER and will not complete any further messages. What I have is a message instruction ladder with a timed trigger to activate a MSG and write the RTC data then time down and connect and write to the next and so on. When it triggers the message instruction of one PLC it also fires an OTE to trigger the BK of the previous message instruction. However it doesn't seem to be actually cutting the message connection and holds it persistent until a power cycle/download event.