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