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