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.
Safe &
Secure
Updating...