Yaskawa
eLearning
You are watching the PLCopen Basics
Video Tutorial Series
This video introduces PLCopen Motion Control
as implemented by Yaskawa's MPiec Controllers
Hi, I met Pelletier
with this overview I hope to put PLCopen
programming into context
summarizing some of the fundamental concepts
such as the Motion State Diagram, General Rules
Initial Value and behavior of the Done Output.
The PLCopen organization has several initiatives
if you go to their website PLCopen.org
this is also evident
there's PLCopen for Motion Control,
for Safety, for Training
all these are listed here at the side of
their website at this time
so a PLCopen really establishes standards in various
areas of industrial automation
and we're looking at Motion Control
so PLCopen.org really is the place to go to when
it comes to knowing any details related to PLCopen.
PLCopen for Motion Control really is just
a motion control specification.
They'll give you the specification for how the different
types of Move Blocks are to work
and then it's up to the vendor to implement
those in their hardware.
So here on the left we see the PLCopen specification
for the MC_MoveAbsolute Function Block
and then here's the implementation in
Yasawa's case of the MC_MoveAbsolute
Function Block
but a PLCopen describes how this block works
and so if there's a PLCopen Move Absolute Block
in another vendor's hardware,
it will work exactly the same way.
This is how we can say that
Yasawa's MotionWorks IEC complies
with PLCopen
while at the same time we don't
have to give away our proprietary internal algorithms
which describe how we make this work
well within our hardware
and so just to make this very clear
the training that we are providing here on PLCopen
does apply to all of the MPiec Controllers,
PLCopen Programming is identical across the
whole product line of MPiec Controllers
from Yaskawa.
It is important to understand
the implementation of PLCopen that Yaskawa
has created, operates these PLCopen Blocks
at the firmware level
and because we've done it at the firmware level
you can almost think of these Blocks
as existing inside the hardware of the controller
and the reason we've done it this way,
one of the reasons, is that
this way we do not rely on the code execution
for Motion to be controlled the Blocks
the Blocks instead are synchronized
and operate in control motion
at the system tick rate
another way to look at that is the Mechatrolink
network rate for those controllers
that use Mechatrolink
Mechatrolink 2 or Mechatrolink 3
and this is the fastest rate possible
regardless of which User Task is used
to initiate the execution.
Now if you go over to the
class project or just even start a new project
you will see this what we call
Firmware Library called PLCopen Plus
here in the project tree
and it go ahead if you want to follow along here
and open up a POU such as the Main POU
really any POU
and you will see in the Edit wizard the
PLCopen Plus group of instructions
and all of these instructions start with the
prefix MC_ those are the PLCopen instructions
and then toward the bottom you'll see that
there are instruction to start with Y_ and those
are the Yaskawa specific Motion Control Blocks
and most of these have to do with
as you can see here electronic camming
or advanced communication features that are specific
to our products that go above and beyond
the PLCopen specification.
Another fundamental concept of PLCopen are the
States of Motion for each axis
so if you could please commit this diagram
to memory before moving on...
just kidding about that!
but what this is showing is that how
PLCopen considers each access to have
a State of Motion and these are the
possible states listed here
and given here in this diagram
and this diagram here shows
which blocks make it possible to move
from one state to another
and for example you can see that if you're in
the Homing state you can't go directly
to Synchronized Motion
you'd have to go first to Stopping
and Standstill and from Standstill you can go to
Synchronized Motion
conventions like this really ensure
that even between one supplier and another
or one platform to another
the way that you create your code
will be the same.
If these type of details are the same
that's the reason for the standard of PLCopen.
Now I'd like to look at the PLCopen
specification document just very briefly
there's a section at 2.4.1
if you'd like a clearer copy of this document
you can go to PLCopen Motion Control > Downloads
and download this Merge of Part 1 and Part 2
and then you'll be able to open up this
plcopen_mc_part1_v20.pdf
document and go ahead to 2.4.1
General rules
a lot of what we'll be showing here is well documented
by the PLCopen organization right here
and now for reference in the video
and the PowerPoint and the Class Guide that
we hand out here are some of the General rules
and so I'd like to highlight some
of these rules with this diagram
and the first of those rules is the concept of
Rising-edge, executing at the Rising-edge
all PLCopen Function Blocks
execute at the Rising-edge of the execute Input
so it's not looking for the state to be high
it's looking for the state to go from low to high
and if that happens in the task that
this block exists in when it sees from one
scan to the next that the variable at
the Execute Input goes from low to high
it will then tell that block to execute
at the firmware level
and it's important to point out the difference
that this block Executes and it Reads the Inputs
also only at the Rising-edge
so if you're to change for example the
Velocity after the Execute Input goes from low to high
that will not have an effect
on the Motion of the block
because Inputs are Read at the Rising-edge
of the Execute Input only.
So upon execution, the motor will produce the
motion that's defined by the Block and
when this Block finishes that command
then the Done Output will turn ON.
The other rule here has Done is exclusive of Error
so if there was some reason that the block
could not operate for example
one of the parameters was out of range
then there would be an Error bit that turns on
and like it says here Done & Error
can never be on at the same time that's just
another one of the general Rules of PLCopen.
Moving down the list here
it also says Positive Velocity, Acceleration, Deceleration
these three values Velocity, Accel and Decel
all must be greater than zero
so well you may think of Velocity as being negative
in order to go reverse truly the way
that you would do a reverse move is
to have a negative distance
and Velocity must always remain positive
and the fourth in the list here is the
Default Input Values
PLCopen states that each of these Inputs
must have a default so that if you don't connect it
there is some default data at these Inputs
to the Block
and in MotionWorks IEC
you can get to this by using the right-click
and choosing Help
and if you scroll down you'll be able to find the
Default value listed for each Var Input.
So let's try this out let's demonstrate that real quick.
You can go to PLCopen
you do have to have one of the code
worksheets open in order to see this group
so we can even look at the Help
without adding it to the code.
Right-click Help and here we see
the Help for MC_ MoveRelative
with Default listed and that is the initial value.
You'll notice that the default for some of these like
Velocity, Accel and Decel is it had to be
greater than zero and the default is zero
so you will get an alarm if you don't connect
Velocity, Accel and Decel because the
default is not a valid entry
and this is done intentionally just for safety.
A frequently asked question is
What is this first column?
It does say with this Tooltip that B is Basic
E is extended and V is vendors specified.
So B means you've got to have it to call this Block
PLCopen but there are some extended
meaning Optional Inputs that you can use
Inputs and Outputs that you can use
and then the vendor has the ability
to add their own.
And now the final general Rule summary
I'd like to discuss is the Done Output
if we look in this documentation
for PLCopen, we can see this part here
that it says it must be guaranteed that
the outputs are set for at least one cycle
if the situation occurs, the situation
I'm talking about is Execute turning OFF
so if you have this situation
where the Move Relative took place
and the Execute Rising-edge started that off
and then Execute is held ON
what do we expect to see at the
Done Output assuming that this Move is successful?
And the answer is that as soon as that motion
is done being commanded
the Done Output would turn ON
and then stay ON until the Execute Input
is reset.
Then it would go OFF together with the Execute Input
but what if the Execute Input is reset,
it turns back OFF
before the motion is complete
then what will happen with the Done Output?
and PLCopen says that it must remain ON
for one scan
and while we're talking about this
Done Output is important to distinguish
Done versus Motion Complete
because while you may have told the motor
to do a profile it doesn't
mean that it exactly followed you
it may be all over the place depending on
external forces or Tuning
and so it Done does not equal what we would call
Position Complete
back in MotionWorks IEC here
Position Complete can be seen
in the Global Variables List
for a particular axis
as the PSET Variable
so this Variable has a hardware address
and is reported back from the
servo into your code.
For those of you who may be familiar with Yaskawa
and the way we do our servos
that's the exact same signal
as what we call the COIN
the Position Coincide
signal and the level for that signal
is adjusted with the parameter Pn522
This concludes the PLCopen Overview
and I hope that this gives you enough information
to get a good start on your programming
and understand how these Blocks generally work.