Hisma

Thank you!  And good point, I used Allen Bradley in my example, but realistically if you have a PLC or device that's got a driver supported by node-red (which there are tons!) this application could easily be adapted to other devices. I'll see about a good general area to post this as well.  

Hey guys, last week I posted part 1 of a series of OPC UA articles in Node-RED. That article covered some important concepts of OPC UA and how they relate to building your own server in Node-RED. I then walk through an example OPC UA Server flow and show how to successfully deploy it. https://flowforge.com/blog/2023/07/how-to-deploy-a-basic-opc-ua-server-in-node-red/ In this second article, I create a more practical example, and show how to build a custom OPC UA Server for an Allen Bradley PLC in Node-RED, including how to encrypt the server connection with SSL to make it production-ready. https://flowforge.com/blog/2023/07/how-to-build-a-secure-opc-ua-server-for-plcs-in-node-red/ I did my best to break everything down into manageable details, so that hopefully even someone with minimal experience can follow it. But ultimately building a custom OPC UA Server does take some effort. My hope is that this tutorial can teach someone enough concepts to go on and develop their own custom OPC Server applications to suit their specific use-case. As always, if you have any questions please let me know! Here to help. note - the full source code is included at the end :). Let me know if you have any questions!

There seems to be a dearth of instruments that natively support CIP safety protocol.  I'm talking things like encoders, sensors, etc.  This means that if you are trying to achieve a high performance level or SIL rating, you need to come up with a more complex design.   Has anyone here worked on some sort of protocol converter as a way to allow a device that talks some open standard, like RS-485 or modbus, and convert it on-the-fly to CIP safety, so that the device data can natively be brought into the safety task?  Seems like rockwell majorly dropped the ball on this.  It's something we're kicking around internally but still very preliminary, and I was wondering if anyone else has tried to go down this path and could give some tips.  

Just wondering what is the best method for recording an accurate sequence of events in control logix. I do not believe that CLX time-stamps events locally, does it? My company has been given a HistorianME module to test out, by our rockwell reps. It seems like a very capable device, and I got it successfully communicating with a CLX processor and Pi server. I have not done much testing with it however. My questions are: 1. To get accurate alarm/status SOE, do I need to poll my digital tags at high speed so events get recorded as fast as the PLC can process it? Or can I poll at a slower speed (say 1 second), and controller-level time-stamping will ensure we have accurate SOE? 2. How do most of you out there handle your event recording? To those of you where sequence of events is absolutely critical, what method do you employ to get maximum accuracy on time-stamps and event sequence?

Thanks for your answers guys. I like the idea of first checking out some open source java-based OPC server tools to start. I watched the vid on inductive SCADA. It sounds nice, but more than we need at this point. I realize I can accomplish the same goal making a "test" or "commissioning" software routine, but I just find that solution in-elegant, and opens you up to problems if your test routine has bugs in it. I like the idea of having an OPC server that can read/write tags directly, as the test is not modifying any existing code, just tag the tag values. Much less prone to error and makes the test environment less dependent on software modification... a good general testing practice. I just wanted to know if what I had in mind is actually possible... and it sounds like it is. Now to start researching the possibilities. Thanks!

Hello all Forgive me, for I am a newb when it comes to this. I do a fair bit of projects that require modifying ControlLogix PLC code, and then testing out the changes in a simulated environment before we go out and recommission the PLC. We have multiple PLCs in our workshop, but sometimes that is not enough to do a thorough testing, as there is tons of field IO that we obviously can't have in our test environment. We already use RSEmulate for doing simpler testing, but when we actually want to simulate IO, and how the PLC should respond to certain inputs coming in, it would be really nice if we could create apps/scripts that write values directly to the PLC tags, and then the script will in turn read in the returned values from the PLC and display them visually. I know you can come up with little DDE VBA scripts, but I dislike the "static" nature of excel spreadsheets, and would like to see if it's possible to develop something a little more advanced using open source tools out there. I am quite comfortable with java, and I see there is java OPC servers out there. I just want to know if anyone has taken on this sort of project, and if it's possible. Maybe there's already something out there we could purchase, or an open source project I could modify for our needs. Any info is appreciated!

I think you are on to something though... there's nothing stopping us from scaling 4-20mA as 0-100% in the card, and then doing all the individual scaling in the logic. hell, we already set the high and low limits in the logic, nothing stopping us from scaling the analog signal itself, similar to using an SCP in an SLC. I'd like to see how some of you in here would approach this though.

This would work, because if you scaled the engineering units as a percentage of 0-100, then every analog would have the same scale, and thus slope, so you could easily have standard alarming that would be identical across all devices. However, we scaled our points with their ACTUAL range... that is... 0-500psi, 0-200*C, etc. So, they're all different, which means 3% of one would be a different value than 3% of another.

I appreciate this response, because it gives me some traction on the existence of a standard across all instruments using 4-20mA range. In my eyes, if we are not being notified an instrument (in this case, a watts transducer which is very important) is out of range until 3.52mA, we can potentially create unnecessary hazards when operating our equipment. So that did answer one of my questions. Now the big question is still, how can I get all of our instruments to fit within that standard, when we use a 1756-IF16 with 0-20ma input range...

hmm, after some quick research I see the card we use is the 1756-IF16, using an input range of 0ma-20ma. In the rockwell documentation, it says under range is detected for this card if it goes below 0mA. But, when you see the scaling for the card, the low signal is 4.0ma and the high signal is 20.0ma. So, it seems almost as though there would be no way to use a raw value to properly detect over range and under range, since the card is set up for 0-20ma input range. Is there some way around this? or is the only other way to use a card that is meant for an 4-20ma input range?

Hi guys This is actually a general question and not directly associated with AB products... though, we do use Control Logix PLCs so perhaps you guys can chime in. Is there an accepted standard for what constitutes an instrument that uses 4-20mA feedback as under range? The reason I ask is because the way my current employer determines if an instrument is out of range is a bit perplexing. They scale the analog signal in the hardware, which makes sense, but they calculate everything else (high limit, low limit, over range, under range, etc) using an analog processing routine. So, when the AI is brought into the logic, it comes in as a REAL number already scaled for it's desired range. Then, it goes into an analog processing routine which then dertermines it's limits for over range, under range, etc.... The problem (in my eyes it's a problem) this causes is that we calculate an under range as 3% below it's SCALED value, not it's raw value based on 4-20mA. What this means is that you can have 2 identical RTDs, for instance, that are scaled differently. RTD 1 would be considered under range at 3.8mA, and RTD2 would be considered under range at 3.5mA. Does anyone else think this is not the correct way of handling this? Is the solution to do either all scaling and setpoints in the card, or all scaling and setpoints in the logic? Are we technically going against the standard tolerance for what deems an instrument under range? I'd love to hear some of your thoughts. I personally think we should be looking at the raw value for determining the over/under range, but perhaps I am missing something.

thanks! I gotta utilize my tech connect agreement here at work, but we do have an account so I can check these out soon. Appreciate the response.

Hi Guys I was wondering if there's a way to make it easy to restore accumulator values after you download new code to the PLC. Obviously, if the code was developed offline, it won't have the current accumulator values. There's ways around this, like keeping a record of current values, reloading, and then "forcing" the values after the new code is loaded. But is there an easier, automated way of doing this? I was wondering if using a historian, you could have a historian server write values back to the PLC. Don't know if that's possible though. anyone have any ideas for this?

Hi guys so after doing some research, I found out all we have to do is replace the cable. We're using a standard 1492 cable to plug into the 1746 IO module currently. The DTM we're using, which is a Weidmuller EA25244, uses a standard 40-pin AB 1492 cable. They actually make 1492 cables that are pre-wired to plug straight in to a CLX chassis. MUCH easier than using a converter. Phew!!

so, after looking at our rough documentation, it appears that this will exactly fit our needs. Brilliant! Thanks so much for this.