Joe E.

MrPLC Member
  • Content count

  • Joined

  • Last visited

Community Reputation

151 Excellent


About Joe E.

  • Rank
    Propeller Head

Contact Methods

  • Website URL http://

Profile Information

  • Gender Male
  • Location Harrisonburg, VA
  • Country United States

Recent Profile Visitors

7278 profile views
  1. Dint to Real

    Round towards 0, round away from 0, round up, round to even...each can cause unexpected results for the x.5 case so you have to know what your platform does and act accordingly. The Logix 5000 PLCs I've used rounded to even; I don't remember what the 5s or 500s did. Or the S7-300s.
  2. Cannot open a FT View Archive File (.apa)

    Honestly, when I first saw this, I thought, "Huh, a new bug I haven't encountered yet." Based on my experience with View Studio, it didn't occur to me to question it. Sigh...
  3. STL

    So, I wrote, and then deleted a little mini-rant about STL programming. This probably isn't the place for it... I will say that not all code can be converted back and forth between LAD and STL. If you write code in LAD and convert it, you will end up with a number of NOP instructions scattered around. Sometimes, you can eliminate them and have it still convert back, other times not. Also, in my experience, code written in STL wasn't divided into networks correctly to be able to convert to LAD. To convert it, I would almost always have to divide each STL network into multiple networks before it would convert. I usually could get it to convert after that, but every now and then I'd encounter one that wouldn't go from STL to LAD. In my experience, LAD would always convert to STL, but not always the other way around.
  4. Allen Bradley 1747-UIC DH485 Issues

    That document is for the AIC module, which is (in my experience) mounted inside the control cabinet to connect multiple devices together. The UIC is a different animal. At a previous employer, we had issues with the white AB UIC adapter being a little unreliable but we were always able to get it to work as long as the cables are good. We ended up switching to the aftermarket model from Industrial Concepts with great results. I never had a problem getting it to connect. Of course, the last time I connected to a 5/02 was a few employers ago and we used an old laptop with a PCMCIA card (PCMK, I think is what it was called in RSLinx...). At my last place we had some 5/03s and some fixed IO L40Bs that used DH485. I found a few in the plant I'm in now but haven't had a chance to hook up to them yet.
  5. In general, parts should be assumed bad until positively verified to be good. I've gone 'round and 'round with manufacturing engineers (newer ones) to explain that it's not enough to have the inspection device just hold its "good" status high until it sees a bad part. What if, for example, it misses the trigger and doesn't inspect at all? The result flag either has to be momentary or there has to be a momentary "inspection done" flag to let the PLC know the result flag is valid. Otherwise you're a failed trigger signal away from allowing bad parts through. Without knowing it...
  6. Remember Me checkbox intermittent

    I figured it was something wonky with our IT policies. I mean, it filters unless I'm on the guest network, so it's not an unreasonable suspicion.
  7. Remember Me checkbox intermittent

    I thought it was just me...
  8. How do you test PLC logic?

    On simpler projects, I would download the code to a bench PLC with all I/O inhibited and then add a "Simulate" program that simulates the real world. So if an output makes a cylinder move, I put a timer on that output and have the timer DN bit turn on the input for the cylinder sensor. This is kind of crude, but for simpler machines, it's adequate. I can extend the timer presets to simulate a dying cylinder or use a toggle bit to disable them altogether to simulate a dead cylinder sensor to see how the logic reacts and recovers. The PLC is in Run mode, and the HMI (usually on the bench next to the PLC) is also being tested. This method is rather brute-force and inefficient and would be cumbersome with more complex machines or processes, of course, but it's served me well on the projects I've used it on.
  9. PN PLC 2 PLC multiple DB's

    The "right" way may depend on who you're talking to... There may not be a way to send multiple DBs with a single connection. Have you tried Siemens tech support? At least in North America, they're pretty easy (and free) to contact. They haven't always been the most helpful, but they're available.
  10. Factorytalk password

    That squares with my experience. We were repeatedly tasked with changing the passwords in a series of machines that all used the built-in runtime security system, which required going out to the machines (about 20 or so total HMIs), editing the project, and downloading it. It was an all-day task that we really didn't have time for. I spent a couple of days figuring out how to let them change their own passwords (very easy) and backup/restore them so we could make runtime changes at will (a lot more complicated). When we investigated doing that to the PV+ HMIs, we found out from tech support that the current password is stored in the MER file inside the HMI, so if we wanted to keep the passwords after making our changes, we would have to upload the existing MER from the HMI and restore it into View Studio. We wouldn't be able to use our APA project backups at all. I'd say to change from using the built-in user administration in the PV+ to using a number stored in the PLC. Make sure you're OK with anyone who can get into the PLC having access to the passwords, though. Then write either a pseudo-random calculation or look-up table.
  11. PN PLC 2 PLC multiple DB's

    Your existing structure shouldn't be affected; you would just add an intermediate step. Create a "holding" DB in both PLCs with the same structure that contains all of the DBs you want to send. Right before you send the DBs, you copy your local DBs to the "holding" DB, then send the "holding" DB. On the receiving end, you tell it to write the data to the local "holding" DB, then you copy it over to your local DBs. Or, create multiple connections. Based on my experience with Siemens processors, I have a feeling that combining them into a holding DB may be easier to follow later, but I could be wrong. Like I said, I've never done this. I don't know how big a deal it would be to have a bunch of BLKMOV FBs running versus having a connection for each DB.
  12. PN PLC 2 PLC multiple DB's

    I didn't study the link in detail, but it looks like the difference between TSEND and TSEND_C is that the _C instruction includes the TCON functionality to create a connection while the TSEND instruction does not. The TSEND_C instruction can exist on its own but TSEND needs either a TCON or TSEND_C instruction to precede it. The link explains that but doesn't provide a lot of details otherwise. If the TSEND/TSEND_C instructions can only send one DB at a time, can you combine the DBs you want to send into one? In other words, create a new DB with a structure that contains the DBs you want to send. I know you can (used to be able to...) declare a STRUCT inside a DB where the STRUCT's datatype is another DB. Maybe try that and have the FC/FB that calls the TSEND/TSEND_C instructions use Block Moves to copy the DBs you want to send into the new DB, then send it. Does that make sense? Alternatively, it looks like you can use multiple TSEND/TSEND_C instructions, each sending one DB at a time, until you've sent all of the DBs you need to send. Caveat: I'm at a new employer who doesn't use Siemens equipment, so I no longer have access to PLCs, TIA Portal, or Simatic Manager to tinker and test. The only time I've set up a data exchange between these PLCs, I used a Red Lion HMI as a gateway device. I've seen it done before over Profibus (a LONG time ago) but never set it up myself.
  13. I can simulate timer

    Good catch. One comment says "50msec" while the other says "100msec". Either way, it'll be too fast to see with the software. I would still expect to see the value of bit Q100.00 displayed the same throughout, though. Weird...
  14. Factorytalk password

    Hmmm... The simplest thing may be to just use Excel's RAND function to generate a series of random numbers to populate a look-up table in the PLC. Here's one idea, inspired by your desire for it to be random digits: It was fairly straightforward to implement in Excel but I don't have a PLC on my desk any more to make sure it yields the exact same numbers. You'll have to do some manipulation (other than rounding/truncating) to make it always be 4 digits without leading zeros if that's important to you. You would also not be able to use the user administration that's built into the HMI. Do you have the source code for the Siemens HMI to take a look at how they did it? If you're using the runtime security functionality built into HMI, I don't know of a way to automatically change the password every day...but that doesn't mean it can't be done.
  15. I can simulate timer

    Not sure what platform it's emulating, but the NC of T0000 may be a problem, depending on what status of the timer it indicates (done, enabled, timing, etc.). If it means the timer is done timing, that looks like an off delay time function. The fact that Q100.00 looks like it's on in the output instruction of the first rung and off in input instructions is suspicious, like the simulation isn't properly running. Or the output is forced. Or something else...