daba

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.  

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.

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.

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.

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

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.

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.

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.

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

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.

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

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.

If you think that's confusing, Ron, have a look at the addressing methods available for the 6502 microprocessor !!

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.

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

See the picture for an example READ from a SLC at 192.168.1.105 : Reading 5 remote integers N7:0~4 into local N7:0~4 The EEM instruction, quoted from the Help Text "EtherNet explicit messages are useful for communicating with third party EtherNet/IP devices that don’t understand standard MSG commands, as well as providing access to data in Allen-Bradley EtherNet/IP devices that isn't accessible via standard MSG instruction commands."

Read this manual carefully. Page 21 specifies "Do not connect a non-DLR device to the ring..... use an ETAP module"

Yes, it appears the option to change the number of data bits has been removed in all of the F/W Revision 10 processors. One has to wonder why, and probably only RA can answer that question...

It is there on my software....

Channel 0 works in either of two modes "System" and "User" : If you want to use the serial port for anything other than programming, uploading, downloading, monitoring, then you will need to set the port to "User". In that mode you can change the number of data bits.

You are absolutely correct, those rungs 1 to 4 will turn the outputs on. I don't know why they were placed there, perhaps (and don't forget it was a student question, and the posted code is all of the code) the thinking was along the lines of monitoring the outputs on the ladder diagram? Or the OP was thinking he needed conditional instructions on the rungs to control the outputs, and hadn't yet put them in..... Your beliefs are true.... The SQO moves the data from one (indexed) element of the source array (file), to the designated destination address, but only where the mask bits are set to a "1" - a "0" mask bit leaves the destination bit unchanged. Of course the destination address for the SQO does not have to be an Output address, it can be used for any purpose.

(1) - The Connection_Status in the consumer is maintained by the system to reflect the success or other wise of the connection. It also informs you the operating mode of the Producer. (2) - The data-type of the Connection_Status element (the first element of the UDT), must be data-type CONNECTION_STATUS - it is already defined. (3) - This CONNECTION_STATUS data-type contains only two BOOL tags, RunMode, and ConnectionFaulted. Note that neither the Producer or the Consumer need to be in Run Mode for the Produce/Consume tags to exchange data. (4) - I don't think it matters what the member-name for the connection status is, but I always call it Connection_Status anyway. And tag and/or member names are "case insensitive". So long as the first member of your UDT is of data-type CONNECTION_STATUS, it will work. HTH

I always take IOI syntax error to mean that the remote tag doesn't exist. However, I'm 99% certain that "MSG instructions can only get to Controller-scope tags" is only a limitation imposed by RSLogix5000 software. I've seen application code that manipulates the .RemoteElement of the MSG control tag, which allows read and write access to Program-Scoped tags. All the drivers out there can access Program-Scoped tags, so why can't native CIP messages, controller to controller....... If I'm right, I can't understand why RSLogix5000 hasn't been updated to allow the remote location to be input directly. This would go along with the "modularity" and "re-usable code" features touted by the sales blurb.

Michael, you really need IT specialist advice on this.... The stations are miles apart, so presumably the connection will involve the Internet ??? But even if they are connected to the same LAN (unlikely), the rules are simple... devices can only talk to devices on the same subnet.... That said, I'm sure there are ways to hop into other subnets, but it definitely would involve high-level IT procedures. You simply cannot talk to just anyone with an IP address without physical and logical authority.

You need LEQ and GEQ, not GRT, to maintain the context of your CMP expression that isn't accepted. I'm still racking my brains to remember how I learnt that only one comparison operator is allowed..... I started training for RA in 2007, and maybe it was in the course material then, but it isn't now, I've checked. Even so, I always make a point of it when discussing this instruction with trainees, on the basis that the expression evaluation ought to be able to deal with the sort of combinational logic you want. It definitely seems logical to me, but unfortunately I don't get a say in how instructions work, I just have to point out the good points, and the bad points. I still maintain that LIM is a better instruction to use... Whichever way round you configure the High and Low Limit values, the output of LIM will be true when the test value is equal to either of the hi and lo limit values.... i.e. reversing the limit values does not invert the output of the LIM.