adccommunitymod (AutomationDirect) asked a question.
Created Date: November 20,2017
Created By: bfitz
**** This post has been imported from our legacy forum. Information in this post may be outdated and links contained in the post may no longer work.****
I'm starting a new BRX program (first time using the Do-More series stuff). I have several analog inputs in the system, and I created a user data type to hold the channel information in a structured way (raw reading, calibration factors, filter time constants, usable reading, etc.) I then created a data block using that UDT. In my program, I'm trying to loop through the UDTs in that data block and (for right now), add the filter logic to take a reading from the .raw location, filter it according to the .filtertc value, and place the result in the .filtered location. I haven't tested it fully yet (just got the hardware put together today, no sensors attached), but the software is giving me a warning about the filter instruction being inside a loop. The actual warning is: AnalogInputs#4(@36) W317 Asynchronous instruction (FILTER) found within loop (FOR at AnalogInputs@15) Is this going to cause problems in the program? Or am I just doing something that is weird, but valid? It lets me ignore the warning and download the program. I'm too new at this PLC to know if it's a bad thing or not. Thanks, Brian
Created Date: November 20,2017
Created by: bfitz
I'm starting a new BRX program (first time using the Do-More series stuff). I have several analog inputs in the system, and I created a user data type to hold the channel information in a structured way (raw reading, calibration factors, filter time constants, usable reading, etc.) I then created a data block using that UDT. In my program, I'm trying to loop through the UDTs in that data block and (for right now), add the filter logic to take a reading from the .raw location, filter it according to the .filtertc value, and place the result in the .filtered location.
I haven't tested it fully yet (just got the hardware put together today, no sensors attached), but the software is giving me a warning about the filter instruction being inside a loop. The actual warning is: AnalogInputs#4(@36) W317 Asynchronous instruction (FILTER) found within loop (FOR at AnalogInputs@15)
Is this going to cause problems in the program? Or am I just doing something that is weird, but valid? It lets me ignore the warning and download the program. I'm too new at this PLC to know if it's a bad thing or not.
Thanks,
Brian
Created Date: November 20,2017
Created by: Mike Nash
It looks like it works OK testing in the simulator. Looped results vs non-looped are identical. But I'm just telling what I'm seeing, not validating it.
Created Date: November 21,2017
Created by: bfitz
I got a thermocouple simulator hooked up to my PLC. After disabling the burnout detection, I have values I can play with. It looks like it's working fine to me too. I did find out that you do NOT want to have the output of the Filter instruction going to a scratchpad memory location that gets reused between inputs! It makes sense after I thought about how the instruction was working.
Created Date: November 21,2017
Created by: bfitz
It looks like SLOPE doesn't work inside a For/Next loop. Also makes sense. It probably references back to the original input value after the timer expires, and in a loop, that might be a completely different input reading.
Created Date: November 21,2017
Created by: BobO
The FILTER instruction is time-based and needs to be solved every scan. Loops are designed to yield after the time slice expires, so it is possible that the FILTER won't get evaluated every scan when used with a loop. If you are sure that the loop won't yield, it's fine to use FILTER. We make it a warning so you are aware.
Created Date: November 21,2017
Created by: Mike Nash
Just tested again with the FILTER and FOR-NEXT in a program yielding every 100uS. Worked fine until I put another FOR-NEXT in just to do busy work to cause the yield to occur, at which point it was very ugly. The "control " FILTER in Main still looked very nice. So we can get away with this as long as the program it is in is set to never yield, or if it does allow yielding, but it never actually has to.
Created Date: November 21,2017
Created by: BobO
Just tested again with the FILTER and FOR-NEXT in a program yielding every 100uS. Worked fine until I put another FOR-NEXT in just to do busy work to cause the yield to occur, at which point it was very ugly. The "control " FILTER in Main still looked very nice. So we can get away with this as long as the program it is in is set to never yield, or if it does allow yielding, but it never actually has to.
That's correct.
Bottom line is that with any instruction that is time sensitive, it must execute once per scan. Discontinuity is bad. And I consider 100 times in a loop with different data to still be once.
Created Date: November 21,2017
Created by: bfitz
Ok, so, basically, it's fine as long as the code block is set to never yield is my understanding at this point. Correct?
Created Date: November 21,2017
Created by: BobO
Ok, so, basically, it's fine as long as the code block is set to never yield is my understanding at this point. Correct?
That is the safest approach, yes.
Created Date: November 21,2017
Created by: bfitz
Would it be possible to suppress the warnings and messages that normally pop up about using those instructions in a code block with yielding instructions if it can tell that the code block is set to "Never Yield " and there isn't a YIELD instruction in the code block?