daba

MrPLC Member
  • Content count

    154
  • Joined

  • Last visited

Community Reputation

4 Neutral

About daba

  • Rank
    Sparky

Contact Methods

  • Website URL http://www.abtrain.co.uk
  • ICQ 0

Profile Information

  • Gender Male
  • Location Cannock, UK
  • Country United Kingdom
  1. TecTeo, I would not "wipe" the data received, but simply would not "use" it if the Produce/Consume connection wasn't valid. Whatever data you need to Produce and Consume, wrap it up into a new UDT that contains, as the first element, the CONNECTION_STATUS (it is a pre-defined data-type). That Connection_Status element contains two bits, which are maintained at system-level... The Producing Controller is in a "Run" mode. The "Connection" is healthy. If both bits are on in the consumer controller, then the data in that consumed tag is 100% valid, and can be used, otherwise discard whatever data is in the consumed tag, or simply ignore it as "invalid". Once you have done this once, and verified that it does actually work, you probably won't be messing around with handshakes or comms watchdogs again.  
  2. Conversely, it doesn't give any limitations, just that is a DINT value, and as already stated, you will have no problems with your 24-hour RTO. Sometimes you have to read between the lines when digesting the Help. Mostly it gives positive information, but occasionally, as in this case, if it doesn't give any negative indication, it's usually safe to assume a positive indication.
  3. It is permissible to put a new module in any chassis, local or remote, and set it up for unscheduled data transfer. If there is no warning triangle on the module when it is not set up for scheduled data-transfer, then it is communicating (producing and consuming) with the controller. If you are not seeing any data from the module, then it may be a module configuration issue. You may need to force-write the configuration tag again if you just change from scheduled, to unscheduled. Unplug the MCM and put it back in the chassis. You can do this with power applied (so long as you are not in a hazardous area). Adding a module into the unscheduled part of the NUT is do-able, but not recommended as a long-term solution. RA recommends that as soon as practical, and safe, it is moved into the ControlNet schedule.
  4. Nothing wrong with b_carlton's suggestion to use COP or more preferably CPS. This is the fastest and cleanest way to do this, and avoids any possible problems with "interrupting" tasks, as mentioned. The main thing to remember is the Length setting, which is the number of elements, of the destination data-type. The cop(cps) mulitiplies this length by the number of bytes of the destination data-type, to determine how many bytes of data to quickly copy from one memory area to another. So ... CPS Shuttle:I.Data[4] My_DINT 1 .... length is 1 because the destination data-type is 1 DINT element - 4 bytes are copied. CPS My_DINT Shuttle:I.Data[4] 4 .... length is 4 because the destination data-type is a SINT (one byte) - 4 bytes are copied.
  5. Be quite clear about this - 80% is not good enough... DOWNLOAD - You would DOWNLOAD only if you have an offline program, already written, that is to replace, completely, and irreversibly, the program in the controller. A Download is destructive, the current program in the controller will be deleted. UPLOAD - You would UPLOAD to read the current program from the controller if, for example you needed to make a backup, or make changes. An UPLOAD does not change what is in the controller. Going ONLINE - In Logix5000 systems (ControlLogix is one of them), to go ONLINE, the offline image on your PC must be the same as what is in the controller. There are many scenarios, depending on the circumstances..... Of course if you have done a DOWNLOAD, you will be making the controller the same as the offline program, and you can go online immediately. If you have the offline file open, and it is the same as in the controller, you can also go online immediately. If you have the offline file open, and it is not the same as the controller, if it is possible for the software to put you ONLINE, it will do so by making changes to the offline file so that they match. This is called "correlation", and depending on which firmware revision/version of programming software, may be automatic, or ask you if you want to proceed. When you come to exit the software, it will then prompt you that "changes have been made to your offline file by the controller, and they will be saved together with any changes you have made"... your choice. If you have the offline file open, and it is not the same as the controller, if it is not possible for the software to put you ONLINE, it will prompt you to perform an UPLOAD, to make the offline file the same. When you come to exit the software, it will then prompt you that "changes have been made to your offline file by the controller, and they will be saved together with any changes you have made"... your choice. If you do not have a matching offline file open, then you should choose the options (when prompted to "Select File"), to modify the search path to the folder where the file exists, (assuming you have a matching offline file somewhere the software can open it from). Once you point the software at where the offline file exists, it will open it, and the above rules will then apply. If you do not have a matching offline file at all, then you should choose the options (when prompted to "Select File"), to create a new file, and UPLOAD into it. Note that in all cases above, the only operation that can change what is in the controller is a DOWNLOAD
  6. S:13 and S:14 will remain at the last values that were put into them, until another instruction is executed that changes them. Although to be on the safe side, I would MOV them to my own storage registers immediately, and not rely on them being changed. Future edits could undermine the philosophy that they remain unchanged. It would be an exceptional gaffe by A-B if the important things in the status file were not saved and restored at the commencement and end of an STI or DII interrupt. I've always believed them to be stored away safely, although I haven't seen any documentary evidence to that. I can also imagine there would be thousands of angry users if status data is not preserved during interrupt processing.
  7. Clearly your auditors are also basing their judgement on the assumed tank dimensions and regularity, with little regard for the accuracy of those. But if you have found a solution that keeps them happy, all is good! Let us continue to hope that the figures they gather are a close enough match to delivered volumes, so that they don't come back later and ask why they don't match.
  8. No, that would not work. The processor would firstly evaluate the bit-wise logical OR of 5, 10, and 76345447, then it would do the comparison once both sides of the comparison operator had been reduced to a single value. If you want to see if a tag is one of several values, you should place EQU instructions on branches.... Or you could perform a "lookup" using a File Search/Compare FSC instruction. The parallel branches would be more readable, and execute faster.
  9. Here you go ... Result in F8:7 BST MUL N7:0 N7:0 F8:0 NXB MUL F8:0 N7:0 F8:1 NXB MUL F8:1 -0.0187 F8:2 NXB MUL F8:0 4.0443 F8:3 NXB MUL N7:0 163.51 F8:4 NXB ADD F8:2 F8:3 F8:5 NXB ADD F8:5 F8:4 F8:6 NXB SUB F8:6 368.98 F8:7 BND
  10. One way of "staging" MSG instruction execution is to trigger them in a periodic task. Include a counter that increments each time the task is run (put an OTU of the .CU bit in the routine, or it won't count more than once). Use the counter's .ACC value to trigger MSG instructions on successive executions of the periodic task. Task 1st Run - Counter.ACC = 1 : trigger MSGs 1 & 2 Task 2nd Run - Counter.ACC = 2 : trigger MSGs 3 & 4 etc. RES the counter when all MSGs have been triggered to repeat the cycle.
  11. CIP question

    Whatever the maximum bytes is quoted, It is much more convenient to think of the limit as 500. 500 bytes = 500 SINTs 500 bytes = 250 INTs 500 bytes = 125 DINTs 500 bytes = 125 REALs Sure, you can squeeze through a few more SINTs, and an extra INT or two, but stating the limit as 500 means you don't have to worry about data-type. My 2c
  12. mhowasso, for all the good advice, and magnificent formulae you have been given, you will ultimately have no confidence in the closeness of the calculated volume to the actual volume. Tanks are rarely "cylindrical", rarely "horizontal", rarely "uniform", and rarely even close to design dimensions. My background is in the brewing industry, which until recently, suffered duty charges on volumes brewed. It was in everyone's interests to have tanks "dipped", to achieve maximum accuracy in volume measurement. "Dipped" meant that the tank was calibrated by filling through a certified flowmeter, and the "dip heights" were recorded as the tanks were filled. The resultant "Dip Tables" (for each vessel, not one for each type), were accepted by Customs and Excise as a true measure of the tank's contents. So, it's up to you - how accurate do you need the volume measurement to be ? Do you need most accuracy when the tank is near empty, half full, or near full ? Or equal at any level ? Each and every method of volume measurement has it's benefits and downfalls, and whilst the "dip" method (you measure the height of the liquid, for which there are several methods) gives you the best results, only you can decide if calculating (based on empirical tank dimensions), or interpolating (based on a "dip-table") is the right way to go.
  13. PLC5 Average

    If you think that's confusing, Ron, have a look at the addressing methods available for the 6502 microprocessor !!
  14. The changes you have to do to the first PLC will have to be done offline, then downloaded, as it involves modification of the I/O.. This will have to be carefully coordinated if the PLC contains any useable production data that you need to preserve through the changes. Making changes offline requires that you have an up-to-date online "image" of the code. Data-table values that change after you have been online and "saved" will be overwritten by the subsequent download. The second SLC can have the code added while online, so no downtime is needed, and no data will be lost. It may be that your SCADA can simply read the existing analog input from the input image, and apply any scaling needed. As is always the case, more info is needed what you want to do.
  15. If they can enter a floating-point number like 0.1, but not zero, then the HMI input data field, or the tag itself is being limited. This will be in the HMI application, not the PLC. Then we must consider that if the numeric input allows a decimal (like 0.1), there must be some conversion to an INTeger taking place somewhere, because an SLC Timer's preset value is an integer, not a floating-point. Also there will be some scaling involved to make that value fit the timebases available (1.0 sec, 0.01sec, or 0.001sec). This scaling might be done in the HMI, or the SLC. My suspicion is that the HMI tags themselves have been limited. You can put any value into the .PRE for both Timers and Counters, however if a timer with a negative preset becomes enabled, a Major Fault occurs, and the processor will shut-down Ken said "I don't know for sure if a Timer's DN bit would be true on the very next rung, or if it would take one scan cycle to become true.". The timer's .DN bit would be set during the first execution of the timer instruction, when the rung is true, it would not need another scan to set the .DN bit. It is effectively a "zero-time timer". For a counter, the .DN bit will be set if the .ACC value is greater than, or equal to, the .PRE value. This will happen regardless of whether the counter is enabled or not