Siemens OB100 Moves

[rQx]

Program execution will not start until startup OB is completed.

I know but the block can take longer then one cycle to complete, so when it is complete and set done or errror you cant evaluate it, hence move the block to the regular OB and start it with a startupflag

 

[kalabdel]

Silly question, does the cycle time watchdog only apply after OB100 finished?

Yes. He can loop the call until done (or error as LD stated; this is actually important) is set and the CPU will not fault.

 

[kalabdel]

I know but the block can take longer then one cycle to complete, so when it is complete and set done or errror you cant evaluate it, hence move the block to the regular OB and start it with a startupflag

I re-read this a few times and I have a feeling you are making a point that I do not understand. Can you re-phrase?


I have no objection to calling this function once ( or on demand) in a cyclic OB (the configuration is stored in the CM).
And at the same time doing this in a startup OB will work and he can add whatever code he likes to validate block execution and do something with that after program start; specially if there's an error he might want to show that on HMI.

 

[Lare]

I re-read this a few times and I have a feeling you are making a point that I do not understand. Can you re-phrase?


I have no objection to calling this function once ( or on demand) in a cyclic OB (the configuration is stored in the CM).
And at the same time doing this in a startup OB will work and he can add whatever code he likes to validate block execution and do something with that after program start; specially if there's an error he might want to show that on HMI.

From memory, port config is started from rising edge of req input.


OB100 is runned only once, yes it is true that it needs to run to end before other cycles are started. But port config won't stop program cycle, CPU would go to watchdog, as port config is several seconds and PLC cycles long, before new config is used.



OB100 can start port config block, but as done and error bits are setted several cycles afterwards OB100 one scan is scanned, they never will update to from instance DB (DB2) to different memory area.


Locate your port config to normal PLC cycle and start it only when new config are needed. Then it will work.

 

[kalabdel]

From memory, port config is started from rising edge of req input.


OB100 is runned only once, yes it is true that it needs to run to end before other cycles are started. But port config won't stop program cycle, CPU would go to watchdog, as port config is several seconds and PLC cycles long, before new config is used.



OB100 can start port config block, but as done and error bits are setted several cycles afterwards OB100 one scan is scanned, they never will update to from instance DB (DB2) to different memory area.


Locate your port config to normal PLC cycle and start it only when new config are needed. Then it will work.

If the instruction is looped, s LD suggested, on condition of done or error, doesn't that mean that the loop will continue to execute, and program cycle not start , until done or error is set?

 

[Lare]

If the instruction is looped, s LD suggested, on condition of done or error, doesn't that mean that the loop will continue to execute, and program cycle not start , until done or error is set?

But why we someone would wan't to loop OB100 several seconds on PLC restart and delay all program executions also several seconds only for that modbus would start.
Port config can be done without OB100.


Not sure of Siemens, but is there possibility, that error and done bits are newer setted by weird errors.

Then normal program execution would never start.
At least loop timeout should be used so normal program cycle would start on all circumstances.

 

[kalabdel]

But why we someone would wan't to loop OB100 several seconds on PLC restart and delay all program executions also several seconds only for that modbus would start.
Port config can be done without OB100.


Not sure of Siemens, but is there possibility, that error and done bits are newer setted by weird errors.

Then normal program execution would never start.
At least loop timeout should be used so normal program cycle would start on all circumstances.

I agree to putting it in a Cycle OB and as part of initial machine setup up of some sort so it is run on demand not every time the CPU restarts.



The code though looks like it would work with no problems and program execution would start on error or done. As to why; well, to each their own.

 

[parky]

Not exactly the same but many years ago I did a system on an S5 155 cpu, this at the time was the largest processor in the range, It had a couple of 232 cards, Sinec H1 so 5 communication channels + WF470 graphics, I had programmed the usual start up in the start up OB for the cards & no problems, Another company won the contract to replace the CPU & Rack with a 945 processor, I was on site that day & the engineer asked me to look at a problem they had as the H1 coms would not start up. I realised that the 945 was a lot faster & concluded the problem was the H1 did not initialise in time. As a quick fix I put a loop to increase the time the start up OB ran before letting the processor go into run, this worked. I too was thinking of checking for status but the concern was if it did not initialise the processor would not go into run. The H1 was not part of a critical process, just sending information to another system for operator information. maybe just put a loop in the OB just to give time for the cards to initialise. this way it will go into run even if it does not initialise, however, It will depend on how critical the communication is, the problem is if it stays in the OB how do you diagnose the problem.

 

[cardosocea]

Yes. He can loop the call until done (or error as LD stated; this is actually important) is set and the CPU will not fault.

I could swear that looping could time out the processor. I can't remember whether it's a setting you can turn off in the configuration or if you can just seet up the timeout period.

This being said, it's unlikely that the Serial Port config would take that long to trigger the watchdog.

 

[rQx]

I re-read this a few times and I have a feeling you are making a point that I do not understand. Can you re-phrase?


I have no objection to calling this function once ( or on demand) in a cyclic OB (the configuration is stored in the CM).
And at the same time doing this in a startup OB will work and he can add whatever code he likes to validate block execution and do something with that after program start; specially if there's an error he might want to show that on HMI.

If you put this in regular OB then you can call the block again if you get error, in startup you cant do that. Im sure you can do it by looping etc but I think you are better off just put in in regular OB and avoid possible other errors that come along with the looping.