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.