OS Start inputon

[macarvajal]

Hello,
We are developing an application based on MC050-120-lg microcontroller. Our application makes use of the input OS Start that, as API doc (70091047) says, should be "set during the first processing time" (page 10). We haven't managed to detect this activation, apparenly the input is never set. Please, could you give us some hint on this question? Is it possible that any sort of additional setup is needed in order to allow the activation of OS Start?

We enclosed a section of the program that shows how we are using the OS_Start input.

Thank you very much in advance and best regards,

[Marbek_Elektronik]

Hi,

I have not tested this, but try this way:

Don't use OS Start.
Use a simple "T" constant and connect this to your on-delay.

I suggest to use for timebase "T100M" and 20 as multiplier because it is more exactly.

Best regards,
Bernd Konrad
Marbek Elektronik,
Germany

[niteRider]

OSStart is only true on the first program loop (like the First-Pass on PLCs) and then goes false.  Likely you won't be able to detect it, since by the time the Service Tool syncs with the controller the First Loop is long gone.  Also, the way you have used it there will never result in a True on the output of your On-Delay... OSStart would have to stay true for 2 Seconds  (that's a bunch of loops, as typical loop time is in the millisecond neighborhood) before you would get a 'True' out of your ON-Delay.  Instead of using an ON-Delay, use an OFF-Delay... you'll see 'True ' on its output for 2 Seconds after startup.

[niteRider]

Also... what were you trying to achieve with the OR gate?  That wouldn't do anything... the output of that OR gate would only be True on the first loop...

[macarvajal]

First of all, thank you very much for your help!

For Marbek_Elektronik,
Yes, you're true. Indeed, we have used that workaround while we keep investigating the cause of OS_Start not setting. The funny part of this problem is that it worked fine on a different version of microcontroller (the MC050-20). We have migrated our code from this device to a new MC050-120 and OS_Start doesn't works in the same manner.

To niteRider,
Right, OS_Start sets only on the first program loop, so we though of it as a good mean to trigger an initial setup and checking task. In a previous version we latched it by means of the OR gate, it is a sort of simple latch (This works fine on the MC050-20):

Initially, OR gate inputs are F, F and its output is F
When OS_Start sets, one of the inputs changes to T and the output is T.
The output feedback into the or gate, keeps the other input to T, after OS_Start changes from T to F.

This latch keeps its output to T forever after OS_Start has been set at start-up. So, it stays true for the 2 seconds needed in the input of the ON-delay line.

We are not using Service tool to check the activation of OS_Start, instead we use it in the program that runs in the MC050-120 (and previously in the MC050-20). Nevertheless, using the "OR latch" described above, we can capture the activation and see whether it has set or not.

We are thinking about the migration from a microcontroller to other as a possible cause. We saved blocks (as SCS files) and reloaded them in the new Plus+1 project. Could it be that this form of copy can take with itself parts of the OS or internal definitions of the former microcontroller?

Thanks again!

[oiltronic]

I use OS_Start on both the MC050-010 and -020 without any problem.  The way the GUIDE compiler interprets the software, I would say that the output of that OR gate latch is indeterminate.  Just use an off-delay timer instead and invert the output. 

The "workaround" of feeding a true constant to the on-delay seems like a more correct solution than that OR gate.  But I would still rather use OS_Start with an off-delay because the purpose is more obvious (and for edge cases where the software might reset for some reason but only produces OS_Start without resetting all timers, so this is more robust in that case).

[Marbek_Elektronik]

I don't understand this.
I think, the "True" and the on-delay ist the best way. Why not?

[oiltronic]

"Best" can be a highly subjective and personal choice.  I prefer using OS_Start because:

• It's very clear to the reader (such as myself after not looking at the software for a couple of years) that the intent is to do something when the program starts running.  Once can quickly deduce how the TRUE-plus-delay works, but the intent for a power-on delay isn't as clear.
  
• The output of the delay after the OS_Start is always determinate from the first program cycle onwards, without having to read a specification somewhere stating how GUIDE software initializes all signals at power-up.  You know for certain how it behaves without having to read anything other than the API spec for OS_Start and the help documentation for the off-delay.  The OS_Start pulse immediately trickles through the delay and initializes the signal downstream.  In most lower-level programming languages it is up to the programmer to choose the initial state for each variable, and it is not clear how the GUIDE programmers have implemented this.  Hence the output of the delay after the TRUE constant is open to debate from the time of power-up to the point where the timer expires and follows the TRUE constant.  Sure, one would argue that it's more logical for Boolean signals to be false at power-up, but that's the point: if it has to be argued then it's not determinate.  Even if a Danfoss programmer chimes in here and says that at power-up things are one way or the other, it shows that we don't know until they tell us.  Finally, the help documentation for the on-delay states:
  
  • X1 = False if A1 = False
  • When A1 goes from False/True, the hold time (A3 x A2) begins
  • X1 = False during the hold time
  • X1 = True when the hold time ends; ; X1 = True until A1 = False
  Given the above, a TRUE constant is always true, so since it never is false it can never go from false to true, hence the output should always be true and the hold time should never occur.  I'm being a little facetious here just to make the point, as I actually believe the delay doesn't work this way at startup.
  

One should try and program by facts, not beliefs.   

[Marbek_Elektronik]

My information from Danfoss is, that at the start of a controller all values are set to zero.
This is, what all programmers should do on lower level programs.
Because of same starting procedure.

But indeed, maybe you are wright, because:

Maybe all values are zero and all boolean values are false.
The question is: Does the software sees an rising edge, because maybe the software sees a True and a True again
and do not read the initialization False before!

[Marbek_Elektronik]

here various modifications:
What do you think about them?