BRX Series PLCs (Stackable Micro Brick) Videos

Hide Transcript

View Transcript

In part 1 we learned that the key to success

with the Do-more is understanding that configuration works best when you do it in a top down order

and that the Do-more is device centric. In part 2, we practiced configuring several

different types of devices and saw several examples of how the top down configured worked. In this video we’ll see how using Do-more

devices can make you much more productive. Let’s start with the bar code scanner on

the serial port. Because the Serial Port Device takes care

of all the details, all you have to do to use the serial port Stream In instruction. Select the Internal Serial port device we

configured, specify how each string is terminated and pick a place to put the result. This instruction needs to be triggered so

I’ll add a contact to do that. Let’s open a data view and add the contact,

the serial input and the serial port In Queue counter that tells us how many characters

the Serial Port Device has ready for us. Download to the Do-more, run the program and

sure enough, if I scan a 10 character bar code I see 10 characters appear in the queue

and if I trigger the stream in instruction by toggling this control bit, we retrieve

those 10 characters. If I scan several 10 character barcodes we

see the in queue increment accordingly, and each time we toggle the C1 bit, we pull another

10 characters out of the buffer. The point here is the Internal Serial Port

Device is doing all the work for us isn’t it? It collects the serial data, puts it in a

buffer, increments the character count in the buffer, handles any necessary handshaking,

etc. We just access that device through its structure

which the Do-more also created for us using this dot notation. All we did was in system configuration pick

which flavor serial port we wanted to use and then issued a stream in command. And did you notice that no other devices showed

up in the Stream In command – only devices that support the stream in command show up

in the list – so you couldn’t choose an inappropriate device if you wanted to! And the best part about using this device

centric model is if you switch devices you ladder code doesn’t change. For example, suppose we wanted to switch this

instruction to an external serial port. Once the device was setup for that new external

serial port it would appear in this list. We would just select that and we’re done. We don’t have to worry about memory conflicts,

buffer overflows, etc. The Serial Port Device takes care of everything

for us and the structure for our ladder code doesn’t change because all serial ports

– internal or external – have the exact same structures. For example, over here in the dataview we

would just change this to New Serial Port dot InQueue. There’s a step by step example of switching

serial ports in this Bar Code Scanning video so check that out if you want to learn more

about using internal and external serial ports on the Do-more. How about the variable frequency drive. Does it work the same way? Sure. In the GS register write command for example,

you would just pick which GS Drive device you want to talk to. The Do-more takes care of all the memory mapping,

hand shaking, all that stuff. you don’t have to do anything because the

device handles all of that for you. That’s the beauty of this device centric

model – all devices work the same way. Let’s do the same thing with the Counter

IO module. To use the encoder, we just bring up the device

structure dot which ever member we want to use. In this case we want this ireg1 register where

the counter result is stored. Again, the Device keeps track of all of this

stuff for us – we just use it by accessing the structure members using this dot notation. Let’s create a second Encoder device on

our counter IO module. System Configuration, nothing to do on the

CPU, We still see our Counter IO module in the I/O configuration, Module configuration. Select the Counter I/O module, edit, configure. We want to setup channel 2 as a quad counter. Let’s name this device Encoder2. Done. We just fully configured a second encoder

on our Counter I/O module. Under Device configuration we see our new

Encoder Device and that there is nothing to do here. I/O mappings – we are not using any of the

Counter I/O modules I/O bits so there is nothing to do here. And Memory Configuration. Scroll to the bottom and we see our new Encoder2

Structure. Hit OK. So to switch our ladder code to use the second

encoder instead of the first one, we just change the structure name – which is always

the same as the device name except it has a dollar sign in front of it - and we’re

Done. That’s all it takes because the encoder

devices all have the same structure, the same interface, the same usage, etc. And if you wanted to do that globally, just

use search and replace. This Device Centric model just makes things

so easy. And keep in mind that while we switched encoders

on the same Counter IO module in this example, we could have switched to any encoder in any

base in the entire system – it wouldn’t make any difference. We would still just change the name of the

device in the ladder instruction – the Encoder device takes care of everything else. Very cool. And there is one more side effect of using

this Device Centric model. What would happen on most PLCs if you actually

REMOVED a module from the local base and put it in a remote base? Yeah, it would break all of your code and

you would have an enormous amount of work to do to get it back up and running – right? Let’s see what happens when you do that

on the Do-more. Let’s power down this Domore, and move this

Counter IO module from this local base to a remote base on the same network. Power up the system. The Do-more immediately seesthat counter IO

module is missing and gives us an error. So we will go to the System Configuration

and just like always, start at the top and work our way down. There’s no change to the CPU. We did change the I/O configuration – we

removed and entire local module from the local base. To add the remote slave we go to our Ethernet

I/O Master because he manages all of our slaves. And before we do anything, we need to hit

this button to male sure all the IP addresses are ok. Looks like our slave’s IP address is good,

but if it wasn’t we would change it here. Now that we know all the slaves we want to

talk to are on our network, we hit this button to add them to the configuration list. This is all the slaves the Do-more can find

on the network. We want to add this one to our configuration,

so we select it and hit add selected. And when we do that, we now see the Counter

IO module in the remote slave here at the top level and here under the Ethernet I/O

Master. We are using a 6 slot base on the slave, so

let’s modify that. Perfect. Go down to the next step – module configuration. You see the new Counter IO module and the

old disconnected one. We COULD delete the old Counter IO module

and then re-setup the new one with the exact same configuration and hope we specify all

the encoders correctly and name everything correctly, etc. OR we could do it the easy way. Here’s the trick – this Assign Config

button lets us take this guys module configuration and simply transfer it over to this guy. We just highlight the one with the configuration,

hit the button and select the module you want to transfer it to. We only have this one module listed here,

but in more complicated systems there could be dozens to choose from. Down here we can choose to keep this modules

configuration –or just overwrite it. We don’t need to keep the configuration

so we’ll overwrite it. If we did keep the configuration, it would

appear back here as a disconnected module like this one. Do-more Designer asks us - are sure we want

to do this – we are. And just like that the entire configuration

is transferred to the new module. We don’t have to do anything. All the same devices are exactly where they

were before. All the same mappings and all the same memory

structures which means my ladder code is oblivious. That’s incredible – that means we have

no changes to our ladder code anywhere in the entire project! Why? Because the ladder code still references the

same device and the same structure. If we write this out to the PLC, the error

goes away. Put the PLC in RUN mode. And look, even the dataview gives us the exact

same result as before. It has no idea we moved that entire module

to a completely different rack. And the reason we could do that is because

the Do-more is Device centric. The ladder code talks to Devices via the Device

Structure. All we did was tell the Do-more that Device

resides in some remote rack now using our System Configuration top down ritual and our

ladder code never knew the difference. It still thinks it is talking to the same

device it was before. The device took care of all the dirty work

for us. We would have ZERO ladder code mods to make,

even though we moved an entire module. If you have ever tried to do move a module

on other PLCs then you know what a monster effort that can be. With the Do-more we just re-assigned the module

configuration to a new module and we were done. That’s the Device Centric model making your

job easier. That’s the Do-more Way. If you have any questions, please contact

AutomationDirect’s free award winning tech support during regular business hours. They will be happy to help you. And don’t forget the forums! There are lots of folks there that love to

share their years of experience. Just don’t post and questions directed at

AutomationDirect’s support team there, they don’t monitor the forums on a regular basis.