Tlogix

I work with a lot of different VFDs thru ModBus and the MSGs in AB can end up being a long ladder project. For example if I setup a system for 20 VFDs of the same brand and customer 1 wants to read/write to 10 registers Thats fine but lets say I sell this to customer 2 with the same VFDs but he wants to look at the same 10 but also wants to look at one other one thats 3 registers lower Like I'm reading 40001 length 10 customer 2 wants to also read 40016 thats when it gets ugly and if you want to keep everything organized you have a lot of addressing changes to make and adding one more MSG between the 2 reads and 3 write you have per VFD. What the Siemens sales person showed me how I could use a MSG or ModBus command in a S7 looks to be what I always thought ModBus should be setup like. For example lets say the customer wants to look at 40001 length 3 then 40015 40018 the way I understand I can make a Block or whatever Siemens calls it to read different addresses in the same ModBus block where in a AB I would have to use 3 different MSGs because of the way the VFD programer decided to structure His Registers If I try and use a MSG to read/write 40001 length 18 if 16 is not in the VFD it gives me a illegal address fault. Thats just one of the problems I run in to and in itself looks like a good reason to Switch I know It won't happen over night but I am willing to learn if I have to. Unless theres something I missed in the AB PLC witch I am sure I didn't.

I was wondering if I'm making a good move switching to siemens its a different animal as far as the programing goes it looks like a steep learning curve. But it looks like as far as the modbus communication goes its a lot more flexible if you have to communicate with a lot of different VFDs. Just wondering if theres some one out there that has switched and how easy or hard did you find it to pickup on the programing?

both of those link are the same software, and I was aware of those before I posted this question, but that can't possibly be the only solution for reading a DLG File from a Micrologix PLC? In order to read from multiple PLC's, parse the data, and make a chart with the data, the end user would have to do a tremendous amount of work for that to happen. There has to be some other way.

Hi All, I'm looking for a piece of software or maybe even hardware that reads a DLG file from a Micrologix 1400. I need to read a DLG, Parse the data and put it on a graph or Chart or maybe just log it to a DB. I have a bunch of remote PLC's that only get read every two minutes or so, they may have a couple of changes happen during that time. We use the DLG file to timestamp the changes and log multiple Bits and Integers. any help is appreciated. Tlogix

(IF) That is the million dollar if. There are several scenarios that I can come up with 1. Service What if it's down for service and the service person locked out the main on the ontrol panel. 2. Time change. What if the user changed the feed time from 6:00 to 5:30 at 5:45. There are a few more that I can come up with. The way the timer works that Ken Roach came up with is foolproof,easy, and user friendly. I try not to deliver controls systems if there's a IF in the loop I try and go over every scenario I can. And still if it hits the real world there something that comes and nips you.

I changed it, when I ran it I noticed it skipped a hour. Thanks

Thanks it looks like its what I needed. Some Times a guy should just take a break and do something els to get the Thinker working again :)

What if it power cycles before the set time?

I am trying to Trigger a event based on Time of day ML1400 I tried using compare but am running in to a problem with the minutes Im trying to latch a bit at 6:30am and unlatch it at 21:30 it works fine if the controller is powered up before 6:30 if it is powered up at 7:00 it has to wait till the next day to latch the bit. I attached a screen shot of the program I also tried using a Limit and ran in to the same problem.

This is what I found I skinned it down from 12 Fans to 3 pumps for my program. This is the original one that I used.12FANS.pdf

If Ken's code didn't work, We would've had to put the Arduino in-Line on the GPS. So the GPS would connect to the Arduino via SoftwareSerial, then the Arduino would give the ML1400 a Serial String from the real Serial Port on the Arduino (pins 0 and 1). It would've worked, but it's just another piece of hardware that we don't want, or need, thanks to Ken.

Hi Guys, So I did some tests with Ken's Logic in a ML1400, and a compared it to an Arduino Uno with the TinyGPS++ Library. Turns out Ken's logic is as accurate as the Arduino, which is as accurate as the Garmin 18xLVC can deliver. So thanks a million Ken!!! if anyone want's the code I used in the Arduino, I'll gladly share it. I used an iPad with mySCADA as the HMI for the PLC and a SainSmart LCD for the arduino.

We need to be as accurate as the GPS puck can deliver, three meters or so. We need to measure anywhere from 0 to 5280 feet. I'll check out your program now. thanks for all the help guys! I'll be sure to post my solution, if I find one.

We're on a 900Mhz wireless network, hence the long polling interval, plus the polling stops when a user logs into one of the PLC's. I wish we could do it with the HMI, that would solve alot of problem's we've had with this system.

We do have a HMI Attached, but we can't use it to do the calculations because of how we handle polling to the PLC's. We have anywhere from 10 to hundreds of these PLC's connected to one HMI Server, and we poll one PLC every three seconds, or upon request from the user. If we have 10 PLC's on one HMI Server, it would take roughly 30 Seconds to make a round to all the PLC's, providing there are no communication losses. However we need the calculation to be run more often than that, about once every two or three seconds.