Move function basics

I'm trying to use a MOVE function as part of a sequence on Siemens S7-1200, but the program control isn't doing what I need.

MOVE in TIA Portal keeps the program cycling while the instruction executes, but I need it to move, then execute the command.

Is there a graceful method of dealing with this? I've been using an equals comparison after the MOVE block, but if the data is in fact equal, that can cause an issue. I also tried re-writing the sequence in SCL but that doesn't solve the issue either.

What makes you think that a Move is executed outside of the PLC main cycle?

What sort of move is it - a large block of data or for example a single int?


Post a screen shot for starters.

BryanG said:

What makes you think that a Move is executed outside of the PLC main cycle?

Click to expand...

I've probably just worded that badly. Although now you mention it I'm not actually sure exactly how the move is executed in the running order.
What I meant is, as soon as the move is enabled, any assignments to the right are also enabled, but before the move has finished.
I remember seeing a Siemens document at one point that broke down the exact amount of time taken to move every common data format, but I can't find it now that I need it!

L D[AR2 said:

What sort of move is it - a large block of data or for example a single int?


Post a screen shot for starters.

Click to expand...

Single piece of data, UInt format.

It's a modbus collector that I did a few months ago, but I'm not happy with the finish so I thought I'd go back and streamline it now that I know more.

All it's doing is running a modbus master block, storing the data returned, then changing the setting of the modbus master and running again.

Originally I used an additional move of a larger data type that was unique to every poll of the master block, but there has to be a better way of doing it.

Puddle said:

What I meant is, as soon as the move is enabled, any assignments to the right are also enabled, but before the move has finished.

Click to expand...

The move will execute and complete before the code to the right is executed.

This is from the TIA Portal help system:

ENO (Enable output) is an output which exists in each STEP 7 block. You can use the ENO to check directly after the call of a block whether all operations in the block were completed correctly or whether errors occurred.

Click to expand...

My reading is that the output only goes high if the block COMPLETED correctly.

L D[AR2 said:

The move will execute and complete before the code to the right is executed.

Click to expand...

That isn't my experience with it. Initially I assumed this to be the case, but then ended up with a lot a conflicts where the settings for the modbus master hadn't updated before the next call.

BryanG said:

This is from the TIA Portal help system:
My reading is that the output only goes high if the block COMPLETED correctly.

Click to expand...

The help file on the MOVE block (v15.1) says this:

Enable output ENO returns the signal state "0" if one of the following conditions applies:
-Enable input EN has the signal state "0".
-The data type at the IN parameter does not correspond to the specified data type at the OUT1 parameter.

Which indicates that it's only there as an error indication.

BUT THEN further down on the example it says:

If the "TagIn" (EN) operand returns signal state "1", the instruction is executed. The instruction copies the contents of operand "TagIn_Value" to operand "TagOut_Value" and sets out "TagOut" to signal state "1".

Which suggests that yes, the ENO should function. I have tried this and it didn't seem to behave how I wanted.

I'm not above discounting the fact that I am, myself, a donut. So with that in mind I'll enable ENO, remove my comparators and report back.

So I'm now pretty sure that the move block is doing what it says on the tin.

I've been so focused on working around that, I hadn't realised there was an overlap in the logic that was keeping the EN live on the modbus master and stopping the settings from updating.

It turns out that this time, it was me, being a donut.

I have often been various forms of confectionery, and I have called myself some rather less polite names as well
'You plonker Rodney' is often part of the conversation in my head. Glad you got it sorted.

999 times out of 1000 it's always something being overwritten.