Created Date: February 23,2009

Created by: bcarlton

Not to disparage the IBOXs but I tend to use the MWX/MRX in stages as you suggest.

Yes, on executing, the communication command sets the busy bit. I then JMP to the next stage where nothing significant happens until the busy bit clears. That tells you that the previous command is done (whether with an error or finished normally).

At that point I do any data processing, if needed using data read (MRX?) by the previous command, then start the next command, JMPing to the next stage.

I don't use a seperate scratchpad area. I give each MRX command its own target area.

By the way, we most often do this with AB Powerflex 4 drives, though we have used others.

Created Date: February 23,2009

Created by: bfitz

Not to disparage the IBOXs but I tend to use the MWX/MRX in stages as you suggest.

Yes, on executing, the communication command sets the busy bit. I then JMP to the next stage where nothing significant happens until the busy bit clears. That tells you that the previous command is done (whether with an error or finished normally).

At that point I do any data processing, if needed using data read (MRX?) by the previous command, then start the next command, JMPing to the next stage.

I don't use a seperate scratchpad area. I give each MRX command its own target area.

By the way, we most often do this with AB Powerflex 4 drives, though we have used others.

Bernie,

I thought you had to wait until the busy bit cleared before jumping to the next stage. ...Looks like it was an ECOM instruction that would need to be actie until the port was not busy to jump to the next stage... I thought the same logic would apply to a MWX or MRX instruction.

Any reason the data processing couldn't be handled in the same stage as the MRX? It seems like that would be a cleaner way to handle the data vs. having multiple stages to handle one network read. However, cleaner doesn't always function properly.

I would be simpler to give each drive it's own target area, but I am trying to conserve Vmem for recipe storage. I might have plenty of Vmem when I am done, but I usually find it easier to save memory upfront than to go back into a program and find ways to free up Vmem and "defrag " it.

Thanks,

Brian

Created Date: February 23,2009

Created by: bcarlton

I guess it's my usage philosophy for Stages. The stage watis for a condition, does something and jumps to the next. The only way to know when a MRX is done is when the 'busy bit ' clears. I don't like triggering the MRX, then waiting for the busy bit to clear to do some seperate action within the same stage.

We currently have an application with 15 drives which are being serviced in round-robin fashion. It's very easy to do copy/paste to generate the rungs. We set speeds and read conditions very quickly.

Created Date: February 23,2009

Created by: bfitz

I guess it's my usage philosophy for Stages. The stage watis for a condition, does something and jumps to the next. The only way to know when a MRX is done is when the 'busy bit ' clears. I don't like triggering the MRX, then waiting for the busy bit to clear to do some seperate action within the same stage.

We currently have an application with 15 drives which are being serviced in round-robin fashion. It's very easy to do copy/paste to generate the rungs. We set speeds and read conditions very quickly.

That's understandable. I was under the (false) impression that the stage HAD TO stay active until the comm was complete. So I did a double take when you said that you jump out of the MRX stage immediately and wait for it to complete there.

I guess that still leaves me wondering when the comm busy bit gets reset. If it is resetting without the original MRX instruction being powered (stage is off), I would ASSUME that the bit is being reset at the beginning of the scan, not when it encounters the originating MRX instruction. If that is the case, then I may have to use separate destinations for all the drive parameters.

Just out of curiousity, are you reading more than one parameter at a time from your drives?

Brian

Created Date: February 23,2009

Created by: bcarlton

I'm not sure where the busy bit gets reset. It may be asynchronous to the scan or it may be at the beginning. But obviously it's not when the initiating instruction is encountered since that stage is off at that point.

Edit - Actually I'm pretty sure it's not asynchronous since some of my code would fail occasionally if it were. - End Edit

With any one MRX we are able to read multiple contigous MODBUS locations within the drive. The Powerflex 4 has 7 locations that provide current status and are readable with one command. We just provide a target group of 7 locations for the info.

Created Date: February 24,2009

Created by: franji1

You may have read somewhere about how the IBoxes work, and those DO have to keep "running " while the transaction is being executed.

Most of the EC* NET* and CTR* IBoxes have built-in interlocking and so they take multiple scans to complete. For example, the ECEMAIL can take MINUTEs to execute because the SMTP (email) server may be slow or you may be sending multiple emails out (yes, SMTP protocol is a one-at-a-time protocol, so the PLC must transact with the SMTP server for each-and-every recipient of an email).

The EC* and NET* utilize the RX/WX instructions, but also use a token passing mechanism that lets you simply perform operations without caring about "busy bits " or "error bits ". They simply provide a Success bit and an Error bit. Typically, in a stage type program, you would transition to the "next " stage when either the Success bit came on or the Error bit (you may even want to transition to 2 different stages based off whether it was successful vs. failure).

What's great about the ECRX/ECWX, NETRX/NETWX instructions is that they do not require any external interlocking, due to the built-in token passsing mechanism inside the IBox logic itself. For example, if you wanted to perform a bunch of READ and WRITE operations, round robin, as fast as possible, out a specific ECOM100 module, all you would need to have is a single rung driven by the _On contact (SP1)

STR SP1

ECRX A

ECRX B

ECWX C

ECWX D

Assuming these are all running on the same ECOM100 module, A would run first, then the exact scan A finished, B would start. On the exact scan B finished, C would run. On the exact scan C would finish, D would run. Then on the NEXT scan after D finished, A would run (since A exists above D in ladder logic, A could not recognize it could "get the token " until the next scan).

It does generate a lot of ladder logic internally "inside " the IBoxes (IBoxes are just ladder macros), but it greatly simplifies the programming AND error handling, running comm closed loop, as fast as possible.

Also (for clarification), there are 2 tokens with the EC* instructions, one for the simple RX/WX transactions, then another one for "high level " instructions like ECEMAIL. This allows the ECRX/ECWX (low level) to keep running multiple transactions per second while the ECEMAIL (high level) is waiting a minute for the SMTP protocol to finish its email transactions.

Created Date: February 23,2009

Created by: bfitz

I am working on a project that will have multiple drives connected to a DL260 via Modbus on port 2. I am planning to use stages to handle fetching drive status and other items in a round-robin fashion. Other stages will handle writes to the drive for commands.

I understand that the writes should be located above the reads in the ladder; is it also important that they have a lower stage number? The biggest thing I am unclear on is when the port busy bit gets reset. I understand that the busy bit gets set as soon as the MWX or MRX instruction executes, but when does it get reset? The question stems from the need to fiddle with the data I receive from the drive before jumping to the next stage. Some of the data I won't need, so my current plan is to read drive data into a scratchpad area, copy the necessary data into individual registers and jump to the next stage. The next stage would clear the scratchpad and execute it's read. I want to copy data to the individual registers AFTER the network read completes (so I don't copy blank data) but before the next stage clears the scratchpad space (again, so I don't copy blank data.)

On a related note, I was looking at the NETWX and NETRX instructions and wondered how the queue is formed when multiple instructions are executing. Is there any mechanism to prioritize the instructions? I was not planning on using these instructions for my project, but I am curious about them.

Thanks,

Brian