The Do-more Way Part I - The Big Picture at AutomationDirect

In this video series we're gonna do a quick walkthrough of a simple do-more control package sorter just so you can get a feel for how a do-more project flows and comes together. Given an application like this where do we start? Well at the end of the day the do-more is just a PLC, so you could just start writing ladder code; And that will work fine but you'll find you have to keep going back and setting things up and configuring things and it just feels like a lot more effort than it should be. But if you have a picture in your mind of how things flow in a do-more design and you design along with that flow. All of a sudden things just fall into place and developing your project takes a lot less effort. We call that, the do-more way, in this video we'll take a few minutes to learn what the do-more way is; And then in the following videos, we'll apply that to the box diverter design and see just how much easier things flow when we do that. When doing things that do-more way there's two graphics you want to keep in your mind's eye: first is the hierarchy of the do-more configuration. You always want to start with a CPU configuration because everything below it can be affected by which options you turn on in the CPU. For example if I enable the ethernet I/O master, it adds another item to the I/O configuration and if I turn it off it goes away. Next you want to configure all the I/O that's the local I/O and the remote I/O. Why, because it can affect all these guys below it likewise the modular configuration can affect all these and a device configuration can affect all these etc, you get the idea. Any item in this list can affect any item beneath it. So it makes sense to start at the top and work your way down. If you do that, then all of a sudden things just start falling into place do you have to do it in that order? No not at all, but you'll find you're doing a lot more jumping around and backpedaling and things will just seem to be a lot harder than they should. And the good news is you don't even have to remember this chart! When you bring up the system configuration look, it's in the exact same order isn't it. Just start at the top and work your way down to configure the system quickly and easily. The second thing to keep in mind is that everything in the do-more revolves around devices. What's a device, you might think it's anything that you want to do-more to talk to. Like a simple I/O module, a VFD an encode or a remote rack and ethernet/ip device etc. But that's not quite right, in a do-more project a device is a little chunk of code that sits between your ladder program and the hardware that you want to talk to. You simply configure the device, this little chunk of code, and it handles all the low-level nasty details for you. The comm protocols, handshaking, memory allocation, etc. You don't have to worry about any of that, which is one of the things that makes programming with it do-more so easy. For example, if we need to use the serial port on the CPU, we just tell that do-more how we want that serial port to behave. by selecting one of these options. Like a general-purpose serial port for Example, then when we configure it the do-more only presents us with the options that are needed for a general-purpose serial port. If we want to use it as a Modbus RTU client port, then we have a few more things we need to configure. And that's a key point that do-more creates all of the devices for you. You just tell it how you want to use the device and configure the appropriate options which to do more exposes for you. And the cool thing about that, is you can't configure the wrong parameter. Since the do-more only exposes the configuration parameters you need; You don't have to worry about configuring the wrong parameter, the do-more won't let you mess up. So, the key takeaway here, is the do-more is device centric everything revolves around creating and configuring these devices. You can think of it like this, here's the device; the device handles the care and feeding of the hardware. An instruction, can only talk to a device it can't directly manipulate the hardware. which is awesome because the device knows how to handle the hardware, how to feed it, how to allocate memory for it, how to handle issues, how to respond to handshaking, how to set status flags etc. It takes all of that hassle off of your back, you don't have to worry about any of it. An instruction can also talk directly to memory, like when doing math. An instruction takes data out of memory does something to it and puts it back in memory. For example a device can also talk directly to memory, maybe the data is coming in that serial port, the serial port device puts the data directly in memory, or pulls data from memory to send back out. All behind the scenes, you never have to worry about it the device just takes care of it sets the appropriate flags, manage the buffers, etc. We call this being device centric, everything revolves around the device. Now as a side note a server is just another device, in that it talks directly to the hardware; But since it just runs in the background, moving data between memory and the hardware like Modbus TCP for example we draw that as a separate device off to the side like this, showing that most of the time it doesn't need any ladder code to function. There are always exceptions of course, but for all practical purposes this is a good representation that reminds us that servers are devices that are there but we never really see them or deal with them directly. And that's it, if you can remember to configure the do-more from the top down and that the do-more is device centric. Your programming will flow so much more effortlessly, your life will be a lot easier, and you will be more productive. In the next video, we'll show you how easy everything gets when you put these two concepts at work as we develop that simple box diverter example. And if you have any questions, please call Automationdirect's free award winning tech support during regular business hours they'll be happy to help. And don't forget the forum's, there are lots of folks there that love to share their years of experience. Just don't post any questions directed at Automationdirect's support staff there, they don't monitor the forums on a regular basis. 01:22 configure all the I/O that's the local 01:24 I/O and the remote I/O why because it 01:27 can affect all these guys below it 01:29 likewise the modular configuration can 01:32 affect all these and a device 01:33 configuration can affect all these etc 01:35 you get the idea any item in this list 01:38 can affect any item beneath it so it 01:41 makes sense to start at the top and work 01:43 your way down if you do that then all of 01:46 a sudden things just start falling into 01:48 place do you have to do it in that order? 01:50 no not at all but you'll find you're 01:53 doing a lot more jumping around and 01:54 backpedaling and things will just seem 01:56 to be a lot harder than they should and 01:58 the good news is you don't even have to 02:00 remember this chart when you bring up 02:02 the system configuration look it's in 02:04 the exact same order isn't it just start 02:07 at the top and work your way down to 02:09 configure the system quickly and easily 02:10 the second thing to keep in mind 02:13 is that everything in the do-more 02:15 revolves around devices 02:17 what's advice you might think it's 02:19 anything that you want to do more to 02:21 talk to like a simple I/O module a VFD 02:24 and encode or a remote rack and 02:26 ethernet/ip device etc but that's not 02:29 quite right in a do-more project a 02:32 device is a little chunk of code that 02:35 sits between your ladder program and the 02:37 hardware that you want to talk to you 02:39 simply configure the device this little 02:41 chunk of code and it handles all the 02:44 low-level nasty details for you the comm 02:47 protocols handshaking memory allocation 02:49 etc you don't have to worry about any of 02:52 that which is one of the things that 02:53 makes programming with it do-more so 02:55 easy for example if we need to use the 02:58 serial port on the cpu we just tell that 03:01 do-more how we want that serial port to 03:03 behave by selecting one of these options 03:05 like a general-purpose serial port for 03:07 example then when we configure it the 03:09 do-more only presents us with the 03:11 options that are needed for a 03:13 general-purpose serial port if we want 03:15 to use it as a Modbus RTU client port 03:17 then we have a few more things we need 03:19 to configure and that's a key point that 03:21 do-more creates all of the devices for 03:24 you you just tell it how you want to use 03:26 the device and configure the appropriate 03:29 options which to do more exposes for you 03:32 and the cool thing about that is you 03:34 can't configure the wrong parameter 03:35 since the do-more only exposes the 03:37 configuration parameters you need you 03:39 don't have to worry about configuring 03:40 the wrong parameter that do-more won't 03:43 let you mess up so the key takeaway here 03:46 is that do-more is device centric 03:49 everything revolves around creating and 03:52 configuring these devices you can think 03:54 of it like this here's the device the 03:57 device handles the care and feeding of 03:59 the hardware an instruction can only 04:02 talk to a device it can't directly 04:04 manipulate the hardware which is awesome 04:07 because the device knows how to handle 04:09 the hardware how to feed it how to 04:11 allocate memory for it how to handle 04:12 issues how to respond to handshaking how 04:14 to set status flags etc it takes all of 04:16 that hassle off of your back you don't 04:19 have to worry about any of it an 04:21 instruction can also talk directly to 04:23 memory like when doing math an 04:25 instruction takes data out of mem 04:26 does something to it and puts it back in 04:29 memory for example a device can also 04:31 talk directly to memory maybe the data is 04:33 coming in that serial port the serial 04:35 port device puts the data directly in 04:37 memory or pulls data from memory to send 04:39 back out all behind the scenes you never 04:42 have to worry about it the device just 04:44 takes care of it sets the appropriate 04:47 flags manage the buffers etc we call 04:50 this being device centric everything 04:53 revolves around the device now as a side 04:56 note a server is just another device in 04:59 that it talks directly to the hardware 05:00 but since it just runs in the background 05:02 moving data between memory and the 05:04 hardware like Modbus TCP for example we 05:07 draw that as a separate device off to 05:09 the side like this showing that most of 05:12 the time it doesn't need any ladder code 05:14 to function there are always exceptions 05:16 of course but for all practical purposes 05:17 this is a good representation that 05:19 reminds us that servers are devices that 05:22 are there but we never really see them 05:24 or deal with them directly and that's it 05:26 if you can remember to configure the 05:28 do-more from the top down and that the 05:30 do-more is device centric your 05:33 programming will flow so much more 05:34 effortlessly your life will be a lot 05:36 easier and you will be more productive 05:38 in the next video we'll show you how 05:40 easy everything gets when you put these 05:42 two concepts at work as we develop that 05:44 simple box diverter example and if you 05:47 have any questions please call 05:49 Automationdirect's free award winning 05:51 tech support during regular business 05:53 hours they'll be happy to help and don't 05:55 forget the forum's there are lots of 05:56 folks there that love to share their 05:58 years of experience just don't post any 06:00 questions directed at Automationdirect's 06:01 support staff there they don't monitor 06:03 the forums on a regular basis English (auto-generated) Videolytics Tools