adccommunitymod (AutomationDirect) asked a question.
Iboxes
Created Date: April 06,2006
Created By: clasentech
**** 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.****
What is the point of the ONESHOT in respect to the existing PD? Is it 100% the same? In 5.1 can you please add a "PID " Ibox and a "2nd comm port " Ibox? You may want to consider a "retenative ranges " Ibox as well?
Created Date: April 06,2006
Created by: timyoung
The documentation for the one shot says
One Shot will turn on the given bit output parameter for one scan on an OFF to ON transition of the power flow into the IBox. This IBox is simply a different name for the PD Coil (Positive Differential).
A PID Ibox is a great idea but there's so many settings. Maybe just include the most important ones? What would they be?
How would the retentive ranges Ibox work. Isn't that something that cannot be set in run mode?
Created Date: April 06,2006
Created by: franji1
Go Tim!
Many people ask why there is no "one-shot " instruction in the DL PLCs. The answer is - there is one - PD. To most people, this is NOT obvious http://forum1.automationdirect.com/board/biggrin.gif
To help them along, if they go to the output column and type ONESHOT - they will get what they want - a PD coil wrapped around a little code that tells us this is a ONESHOT IBox and not just a regular PD coil.
A PID IBox may be doable, but it would be VERY complex, as timyoung mentioned.
Also as Tim mentioned, retentive ranges must be configured before going to run mode, hence you cannot configure it programmatically. Also, it is stored in an area of internal memory that is not accessible to the ladder program.
Created Date: April 06,2006
Created by: clasentech
So the point of the ONESHOT is so you don't have to read the "manual ".
The PID Ibox could simply mimic the stuff that is in the PID pop-up window. That way everything is coded easily within the ladder logic. I'm not saying it would be easily implemented by you all, just suggesting it.
Oh, I read the documentation on the PD/ONESHOT, which led to the question. (occasionally I read the manual too... occasionally)
Created Date: April 06,2006
Created by: franji1
The PID configuration dialogs contains 7 tabs, all of which contain 7+ things that must be configured. That is one IBox with like 50 parameters - for just ONE PID loop - not counting Ramp Soak tables, which would need to be another IBox.
It's not the difficulty at our end - its trying to figure out how it needs to work a lot better than the current mechanism.
Created Date: April 07,2006
Created by: marksji
While we 're on the topic of Iboxes...
If I can do something without an Ibox (like write data to another PLC), does using an Ibox instead of the multiple commands use up more program memory?
I 've been pretty busy the last few weeks, but I 've seemed to notice that I sure run out of program memory fast when using Iboxes (particularly network Iboxes).
Created Date: April 07,2006
Created by: franji1
Originally posted by marksji:
If I can do something without an Ibox (like write data to another PLC), does using an Ibox instead of the multiple commands use up more program memory?
Yes - there is overhead with IBoxes. The more parameters an IBox has, the more overhead there is in order to "reverse compile " the IBox. In ladder memory, this overhead consists basically of data and perform like a NOP.
Note that the Math IBoxes have minimal overhead, these basically have one parameter, regardless of how complex the expression is.
Unless you are actually running out of program memory in your CPU, stick with IBoxes - you paid for the memory in the CPU whether you use it or not.
Created Date: April 07,2006
Created by: bcarlton
Echoing Marsji's observations - I have grown fairly comfortable with doing fairly complex things with the lowest level commands, though I really like the Modbus command for the ease of entering the Modbus addresses. Possibly the math evaluation IBox would be the one I use the most. Is there any way of publishing the memory/execution cycle hit that the IBoxes bring?
Created Date: April 07,2006
Created by: franji1
The memory used is IBox and parameter specific. Just enter what you want and see how many addresses it takes up.
The overhead is basically NOPs. I do not know how long it takes to execute a NOP, but I'm sure not very long. The MATH IBoxes are minimal compared to the other IBoxes.
If you are doing ANY kind of Math (even integer math, with or without IBoxes), the overhead of the NOPs are minimal compared to the actual math instructions.
Created Date: April 08,2006
Created by: marksji
franji, in working on an existing product at my desk I only had a 260 CPU handy so I popped that in my base and started working (the actual product uses a 250-1). I wasn't paying any attention to ladder size, but I did go through and "clean up " a lot of my code for networking this product back to 12 others... The iboxes made my code a LOT easier to read (comms with 12 other PLCs at about 4 writes and 4 reads each), but it ate up more memory than I would have thought (discovered this when I went out into the shop and tried to load the program into a production product with a 250 cpu and it wouldn't fit) so I un-did all my "clean up " work.
I will say the math iboxes have really made life MUCH easier.
Created Date: April 08,2006
Created by: franji1
Mark,
If you run out of memory - start with eliminating the IBoxes that have the most parameters and rewriting the logic yourself.
However, if it is an IBox with a Config IBox (e.g. ECOM100, NETCFG, or CTRIO), you 're best off sticking with all IBoxes because rewriting it from scratch can be a bear!
Or, upgrade your 250-1 to a 260 http://forum1.automationdirect.com/board/wink.gif