Damian

You have to tell us what protocol you are using. You get 4 sockets, that's it. If you want to talk to 6 devices you will need to share a socket or two and do some multi-plexing (opening / closing sockets as fast as you can)

You might find the last 2 posts of the following thread useful if you decide to try the above. http://forum.unitronics.com/index.php?/topic/582-clampers-clippers-and-crowbars-oh-my/page__p__2333__hl__resistor#entry2333

As a cheap way out......... You can always just run the mA signal through a resistor bridge and then measure the voltage across instead. Just be careful to how you source it such that you don't overvoltate your input in the event of a wiring error. You might be able to use one of your analog outs as the source.

Are you using Volts or Milliamps? Did you set the jumpers correctly on the E3xB? Can you provide a description or sketch of how you wired them? Did you bring power to the "0V" and "V2" terminals on the connector with the Analog outputs (this also powers the Analog input circuitry)?

Hi Joe, A transition contact is executed only based on the state of the memory location referenced by that contact. The ONS in AB instead executes based on the RLO condition of the entire branch preceding the ONS intruction. They can often be used to achieve the same result, but they really are fundamentally different. Actually would be a good wish list item for NG. An ONS type instruction. I also wish AB would add the P and N contacts as well. Don't want to be nit-picky but I have seen this trip up many in the past that have had to transition between PLCs that do it one way and those that do it the other. Lezalex, Also in support of what joe mentions in line item #4, it is a good idea to have your screen calls triggered by transition contacts. Otherwise you run the risk of having strange phenoma happen such as re-invoking the same screen consecutively. It might be helpful to have a separate subroutine (maybe name it "HMI") that is a collection of all your screen calls in one spot. There are definitely a lot of other issues as well. I would recommend breaking this up into smaller chunks and get each of those chunks working properly on their own before trying to tie it all together. D

Assuming your valve is normally closed (Output ON = Valve Open) If your switches are normally open (input is ON when full) then put three normally closed contacts of your inputs in parallel with your valve output. The pump will remain on until all three of them are open. If your switches are normally closed (input is OFF when full) then put three normally open contacts of your inputs in parallel with your valve output. This is the most crude method, however it would be wise to implement a timer in here as well to make sure you give the system some hysteresis.

To close the loop on this .................. If you end up in this thread and wonder what ended up being the DF1 stability issue I was having, please search for "Trouble with SLC communication" in this forum. There was a bug with the DF1 comms that was discovered and fixed.

See also this thread from the "old" forum http://www.unitronics.com/forum/topic.asp?TOPIC_ID=2115&SearchTerms=DF1 It may help with you MBs

Sorry for the late reply, were you ever able to figure this out?

First thing is to definitely make certain you have the most recent OS in the V350. There was a bug in the DF1 block that caused abnormal behavior depending on what data and addresses were used. Second thing is a warning that the document you are referencing does have a few errors. It is definitely useful, but there are some inaccuracies. Unfortunately, I failed to properly take note of these back when I was doing this myself so I am a bit rusty on those details. There were also some address ranges that quite simply could not be accessed for whatever reason I was never able to figure out. If I get time I'll give it a try again a bit later. Good Luck

"Do I have to run PID Autotune process every time the user changes the SP value? (Detect change in linked MI value)." NO Do I have to write 6 different autotune codes for each loop? YES

Take a look at EWON. http://www.ewon.biz/en/home.html

+10

Create a new "scanner" and have it point to the block of ML's you wish to access. For the data address, use 28672. Set length to however many ML's you want, and then select Holding registers. It is common that using a function call to the holding registers implies the 40001 offset, so you likely just need to give the sub-offset. Otherwise there is no point in selecting "holding registers" since the 40001 and up range is the holding registers by definition. Now when you create your variable, that offset will be in reference to the block your scanner is reading.

This tire has already been kicked a few times. http://forum.unitron...ch__1#entry2997 That was related to T/Cs, but really it is the same question. Some things require jumpers, but even so, the ability to select in software still allows the operator to make the jumper change only without fussing with the program.

I think the answer to your problem may be simply that you have tied the PID config block directly to the rail and are executing a re-config every scan. Use and SB2 contact between the config block and the rail and let us know how you make out.

I agree that the series connection isn't working because DW1 gets modified while the network is being processed. I completely DISAGREE that it should be evaluating the ladder like this. Each instruction in a rung should only be executed ONCE. This means that once the comparator is evaluated, it should retain the state of that decision until the rung has been completely finished executing. What is really happening is the rung is going back and re-evaluating the comparator for subsequent conditions. Looking at the STL generated for the rung, you can see that Visilogic is not properly translating the ladder as written. It is clearly evaluating the first comparator instruction TWICE. It should not be. This is not in line with any other translator that I have ever seen. It is completely unintutitive, and breaks from the "left to right" execution convention that everyone expects.

You need to know the "name" of the unit and what port you are using. If your sockets parameters remain default, your port number can be 20256 As far as the name of the unit, you need to use a NAME function block in your program and assign one yourself. Another option is that the default name will be the serial # of the unit. You can view this entering "info mode"

Based on your original diagram, as a result of the miswiring is it very plausible your sensor outputs were damaged. Pay close attention to Simons & WalkerOKs diagram, as it shows that for an NPN sensor you need to bring +24v to the input commons. Also, keep in mind the real difference between and NPN and PNP sensor. A common misconception is that with NPN you get 0v for ON and +V for OFF, and for PNP you get +24V for ON and 0V for off. In reality, for a PNP sensor you get +V for ON and "Open Connection" for OFF. By the same token for an NPN sensor you get 0V for ON and "Open Connection" for OFF. In this fashion, you need to be careful how you measure the output of an NPN sensor in order to truly understand its state. You will get different readings based on whether your sensors signal wire is unhooked or is still connected to the input. This is because the input device is normally either "pulling up" or "pulling down" the voltage across internal resistors. In short, the sensor provides the ON voltage state, and the input provides the OFF voltage state. Just to make certain you have your inputs "pulled up" correctly, touch 0V to a spare input and verify that you see the state of that input change.

Depending on what exactly it is you are doing, you might be able to use indirect addressing and cut way down on the number of screens. But like Joe says, if you have that much going on why not jump to the V120? The capability and software are vastly better.

I was unable to open the new document

Welcome to the form! Nice job on providing most of the details on your project. First quick tip, save your word document as a .DOC instead of a .DOCX. There are many out there that do not use the newest version of word yet and will be unable to view your file. *************************************************************************** "Is there a concern having two separate power supplies?" No concern, it is actually better to do it this way. It will help isolate the kickback from your inductive loads from wroking its way into the controller. In addition, you should use snubbers on your solenoid coils to help prolong the life of your PLC outputs. You may also consider fusing the outputs, or at least the power feed to the outputs so that a bad ciol or short doesn't blow your output/outputs. ********************************************************************************** "Why does the PLC logic remain at 1 when the sensor state changes when sensing a target?" Your wiring diagram does not make sense. It shows all of your input tied "ON" all the time. It shows all of your prox swtiches shorted. The browns and blacks shoudl not be tied together. Each black wire should come back to a separate input. Each Blue wire should go to 24V common. Each brown wire should go to +24VDC. ************************************************************************************* "During debugging mode, the Output logic value is "1" when the solenoid is in use. I cannot switch the state to 0 using the reset button in the PLC software" "Why doesn’t the solenoid engage when I manually change the state of the solenoid in the logic?" Because your program logic is overwriting it. You are using "output energize" instuctions. They are updated every scan based on the true or false condition of the logic preceeding it.. ************************************************************************************************************************ "When I toggle the state of the unused solenoid, I can hear the relay inside the PLC make a click sound confirming that the internal relay is functioning" "Is this directly related to a wiring problem with the input and output wiring?" Your wiring diagram does not indicate you are providing power to your relay outputs. ********************************************************************************************************************* You should provide a description of what you are actually trying to do with your application. It is difficult to comment on your ladder program without the context of knowing what it is supposed to be controlling. D

Hi Simon, For what it is worth, I think it is a great idea. D

Ah, the dread navigation panel. Search for this thread "Browsing Quirk" http://forum.unitronics.com/index.php?/topic/871-browsing-quirk/page__p__3273__hl__quirk__fromsearch__1#entry3273 They said they were going to fix that. Hopefully Simons fix suggestions will help you more than they did I.

Its just modbus.