wander_who

rpraveenkum... I'd be suprised but happy if you could solve my problem just by looking in the manual... but here it is: roc_etip.pdf We already have two identical setups elsewhere, that are working fine. It would be great if I could at least identify the problem as the PLC or the touchscreen! Cheers, Andrew W

Hi rammin48 Something does not sound right there. As I said, my understanding is that CIP is the protocol and EtherNet/IP is the network etc... People feel free to correct me if i'm wrong! Regardless, everyone else.. HELP! If I can't get it to work, I am faced with changing the Pro-face driver to DF1 (serial), and having to change every single tag address in the touchscreen program to an SLC-style file address, and mapping these with RSLogix5000. I really don't want to do that.. and i'm not even sure it would work.. will I get the same or similar error?? Besides, it would remove our ability to "see" the touchscreen on the network, upload or download, etc. Other than that, i'm out of ideas. I'm still talking to my Allen Bradely rep & Pro-face rep... nothing yet. Cheers, Andrew W

rammin48... I just had a look in the Pro-face manual for the Rockwell EtherNet/IP driver, it says: "Rockwell EtherNet/IP driver for GP uses te CIP protocol..." rpraveenkum... The Pro-face touchscreen does not use that format for entering the communications settings, (only the IP address, subnetmask, and gateway)

Hi rammin48, Not sure how to verify that the CompactLogix PLC is using EthernetIP ? I thought that CIP was the protocol and EthernetIP the comms network ? Anyway, the Pro-face touchscreen has many comms drivers. The one i'm using is the CompactLogix / ControlLogix native ethernetIP driver. Extra info: On the last project, initially I started out using their AB CompactLogix / ControLogix ethernet driver, which requires address mapping using RSLogix5000 to map tags into SLC-style files... but then they released the CompacLogix / ControlLogix native ethernet driver, which can use the PLC tags directly (any data type). The first driver worked fine, but was a pain due the address mapping... So 'native' driver was much easier, and worked fine... that project is still running fine so I am stumped for what the problem with this new project could be! Cheers, Andrew W

Hi newpageboba, The PLC & touchscreen are connected to a local unmanaged Hirchsmann Spider 5TX 5 port switch. The customer's network gets comes into this switch also, but even when it is disconnected, we are getting the same error. At one site, I had the guy try connecting directly from the PLC to the touchscreen (with a crossover cable) - same error So I am thinking it could be a problem or setup problem on the PLC side. Anything I should check with the setup of the ethernet port ? But we can go online with RSLogix5000 fine, upload, download, (locally, and over the VPNs too), and our VB HMI program can communicate fine with the PLC (via RSLinx DDE)... so it can't be that ? I don't know what else to do! Cheers, Andrew W

The problem is local (the PLC and touchscreen are right next to each other) Both devices have been allocated static IPs, and both devices are on the same subnet. There is also a default gateway set in the PLC and the touchscreen. The PLC has some DNS server addresses set, but the touchscreen does not. But there should be no need for the DNS servers... All devices are local and connected to the one switch. Connected to the switch is: one touchscreen, one PLC, one computer, and the customer's network connection (to allow us to come in via the VPN). I'm not sure about the firewall, but its a local comms problem, so any firewall shouldn't effect it... Both sites have the same problem - even if the customer's network connection is pulled, the touchscreen is still unable to talk to the PLC... At one site, the VPN connections is a Cisco VPN (with this one there is some unresolved problem with the setup which is preventing me from pinging either of the two devices, but is a teething problem, the exact same setup is working at other sites) The other site's VPN is just a windows VPN, and I can see all devices. Cheers, Andrew W

Hi all, I am trying to solve a communications problem, between a Pro-face AGP3600-TI-D24 touchsreen and an AB CompactLogix PLC. The touchscreen does not seem to be able to communicate with the PLC, although maybe one or two buttons appear to work. The error on the touchscreen is: " RHAE132:xxx: Error has been responded for device write command (CIP error code:[05H]) " (where xxx is the name of the PLC). The strange thing is that we have exactly the same problem at two totally different installation sites right now, at the same time. Everything is basically the same, except one site has an L32E and the other an L35E. Both screens are using Pro-face's "Rockwell CompactLogix Native" ethernet/IP driver to communicate with the PLC (allows the use of direct comms with tags etc, no need for address mapping). Even stranger, the previous installation where we used these screens worked fine. That site had two PLCs & two screens. Same model touchscreens, same drivers, and same PLCs - one L32E and one L35E. In fact, the touchscreen programs and PLC programs I am using for the new systems are simply modified versions of those used on this previous installation. The Pro-face manual says that this Pro-face error code means a failure to write to the PLC. I could not find any reference to the CIP error code in the AB literature. I have asked our Pro-face supplier, they have checked with head office, and reported that the AB CIP error code (05H) means "Local processor is off-line (possible duplicate node situation)", and that they suspect a duplicate node (I'm not sure if 'node' is interchangeable with IP address...) While there are a few network issues (mostly VPN related), all local ethernet network communications (RSLinx etc) seems to be working fine. Besides, the LAN at each site was used to transfer the touchscreen program (actually via the VPN at one site), so that much is working we know. At one of these sites though, it did take a long time to get the Pro-face software to be able to communicate with touschreen, to transfer the program. We had to mess around with port numbers etc, before it would work. But after that first time, it now works every time. Currently, both touchscreens have the port set to Auto. I suspected network issues at the time, as it had all just been set up then... but now the network is fine (eg now am PLC programming remotely via the VPN etc) As I said, I was thinking that both sites have some network setup problems - but what are the changes of two totally unrelated sites & systems both experiencing the same problem, and both being due to network issues? Besides, the previous two systems worked fine... I have checked all settings on the PLC, the PLC ethernet port, the touchscreen, port settings, IP addresses, everything, but no luck. Any ideas ? Cheers, Andrew W

Hi all, Delayed response here.. just thought I should let you guys know how I went. I put the counter on an unconditional rung in a periodic task, and got rid of the timer (the interval is now set by setting the period of the task). All working very well Thanks for the help. Cheers, Andrew W

No it's not PWM or anything like that.. and there is no connection to the PID loops... Just one tag that is true every 1 in 40 counts, which is just used to synchronise the start, or the end, of a burst of gas & air, for example... and also to make sure each burner starts a small amount of time after the previous one, and in a particular order (staggered and spread out) The PID loops are in the periodic task, running at the same (total) time, 8 seconds. (40 x intervals = 8sec) The PID control is fine - both the code & the resultant temperature control. Yes, looks like a periodic task is the way I will have to do it for now (regardless of wether it is deterministic or not - i will soon find out how good / bad - but in any case, it will be better than a compound 125ms error!) Cheers, Andrew W

BobLfoot, ok well I guess thats why I shouldn't do maths at 4am yes, 1.4ms was totally wrong ! Peter, 1. Very simply, the pulsing is to control many burners, the outputs driving air & gas valves, in an on/off fashion. (pilot light or high fire). The time spent on is determined by a pid loop, among other things. (not necessarily 40 pid loops though). All for temperature control. 2. A high speed card might be an option in future programs, but unfortunately not with those i'm currently working on. I have often thought about getting more precise with the control.. 3. ControLogix instead of CompactLogix... could be an option, but the deciding factor would always come down to $$. Hypothetically, if I used identical code in the ControlLogix, what sort of reduction in scan time could I hope to see ? Gerry, My experience with periodic tasks is limited to a handful of plc programs that are all basically the same as this one. We only started using the CompactLogix 2 (3?) years ago.. before that were a few SLCs... So, It looks like my only option at the moment is to move the code to a periodic task, and count each time it is scanned rather than using a self-resetting timer for the intervals between counts... (is that correct?) No special instructions that can give me a pulse every x ms's, or a pulse output ? Cheers, Andrew W

Hi all, Been away for a while - had to remove everything from my old laptop and am using another temporarily... Thanks for all the replies.. everything has been helpful so far. Ok, specific replies/further questions: - Peter Nachtwey, mbrugman: By interrupt do you mean a periodic task? - Peter Nachtwey: About not cascading timers... There are two main routines that call all these JSRs. In the first main routine, there is only one timer, and one counter, other misc logic, and 40 JSRs. In the subroutine called by these JSRs, there are no timers or counters. (althought there are an additional two nested JSRs, but they are conditional and so will only be called once every 8 seconds) In the other main routine, there are 40 JSRs only, and in the subroutine called by these, there are two timers and one counter. But these are conditional and will very rarely (in terms of PLC time) be enabled. About the real time clock or millisecond clock, and counting interrupts: I don't quite understand your example... I know what you mean by the real time clock, but I think I am missing something with your description of how to use it or a millisecond clock (DoSomethingTime etc) About jumping over code that doesn't get executed: I understand this and agree.. but the problem is, the structure of the code requires the subroutine to be called every time, even though certain logic in the subroutine may only be executed once in every 40 counts, there are many lines of logic that is executed every scan. (See my comments below about re-writing the program, too) - BobLfoot, TWControls. Basically I am using a new program that I wrote, 90% of which is code written from scratch, but made to match standard algorithms etc (so that it matches our other progam, for Omron plcs). Unfortunately, the only part of the program that I did not change from it's predescessor (written by someone else), was this routine and the subroutine. I did add perhaps 50% of the input & return parameters - but the structure is unchanged. The other downside to this, is that I cannot afford the time for a rewrite at this stage, and would also like sort of fix that I could apply to the existing systems using this program structure. - Gerry, mbrugman: Gerry suggested to use a periodic task and count up every time it was scanned, but mbrugman thought that this would not be repeatable enough. As described in my previous post, the 'pulse' needs to be 100% reliable, or it will effect the temperature control process... About using DINTs instead of INTs: I have hardly any INTs in my PLC program (other than I/O tags, such as t/c inputs) - TW Controls About posting my program...well I am not sure I can/should? After all, it has taken me a while to convince the powers-that-be of the need to control our PLC programs, rather than leaving a copy on every customer's computer, all over the world... However, I do know that the bulk of the scan time is taken up by this one program (containing the two main routines with the JSRs, as described above) in the main task, so posting the rest of the plc program wouldn't be of much use, i think. I could post specific parts, I suppose ? There really isn't much to it that I already haven't posted! - TWControls & others: About scan times... Well, I just checked it again. II monitored the main task, cleared the max recorded scan time, and then watched the scan time. It has been stable at around 90ms so far. The scan time of the one program in question is about 25ms. All other programs in the main task are less than 10ms, most less than 5ms, and quite a few are less than 1ms. The only other task is the periodic (every 8 sec) PID loops taks. It's scan time is about 15ms. - TWControls About scan times per instructions: From the manual "1756-rm087_-en-e" (controllers execution time & memory use reference manual May 2005), the execution times of the JSR/RET instruction pair, for the L32E, is 10.6us + 2us per parameter. This means, for 40 JSRs with 15 inputs/14 returns + 40 JSRs with 12 inputs/8 returns + 40 JSRs with 5 inputs/4 returns, the execution time for all JSR/RET pairs only, would be: 1.4ms - TWControls & others I went to a Rockwel seminar about the new rev16, and am hanging out for these instructions. However, in the mean time, I had been thinking about modifying the JSRs: instead of using up to 15 input parameters + 15 return parameters, perhaps I could use a user defined data type, and (eg call it "Burner Pulse"), which contained members that matched the number, size, and data type of these parameters, and simply pass it to, and return it from, the subroutine, for each JSR ? Could I expect a big decrease in scan time if I streamlined it this way? Ok. Sorry for the long responses. Now, I should say that every tag passed from the JSR as an input parameter or return parameter, is one member of an array. All JSRs use the same parameters, just each one has a different index (eg 40 JSRs, so array elements 0 to 39). Example of one of the 40 JSRs: 15 input parameters, 14 return parameters input: 9 are one element of a DINT[64], 3 are one element of a BOOL[64], 2 are one element of a REAL[64], and 1 is a BOOL (a real I/O output actually). return: 11 of the return parameters are the *same* tags as the input parameters (all the array tags), plus 3 BOOLs (real I/O outputs). Do any of the following greatly increase execution and/or scan time: - Passing real inputs or outputs ? - Returning the same parameters that were passed as inputs? - Passing REALs - Passing BOOLs Lastly, back to my original question: As Peter Nachtwey said: "The events can't have any better resolution than the scan but at least the errors will not accumulate" (using his interrupt idea) So... short of a small or big re-write... is the interrupt idea the only thing I can do to improve the accuracy of the timer & counter combination ? (If so, as I mentioned above, I'm don't quite understand his example, so if you guys could elaborate...) What else I can do ?? Cheers, Andrew W

Hi TWControls, There are two tasks - one main continuous task as mentioned previously, and one pid loops periodic task with 32 pid loops. The period of the pid loops task is set to that total time I mentioned in my previous post, (eg: counter preset x timer preset = 40 x 200ms = 8 seconds) There is a lot of other code in the main task. One program contains this pulse timer & counter logic. The scan time of this program is about 20,000us. In this program, there are 10 routines (most ladder, some structured text). Two of these routines are the main ones, and each has 40 JSR's. Each JSR has up to 15 input and 15 output parameters. Every JSR has one input as an input parameter and up to 3 outputs as return parameters. Also, every JSR has a BOOL 'pulse' flag (set when the pulse counter equals a certain value) as an input parameter. As the JSRs are all continuously scanned, the pulse flag triggers logic that determines if the outputs should remain on or be turned off, and how long between changes in on/off state, etc. (This is all for a temperature control process, for which the pulse flags synchronise the start & duration of a number outputs such as burner air & gas valves) The timer, counter, pulse flags, and logic that gets triggered by each flag, are all used only within this one program and its routines. The tags for the timer, counter, pulse flags, and a few others are all controller scope, all other tags are program scope. Hope this info helps ! What kind of scan time should I be expecting ? Cheers, Andrew W

Hi all, This is what I have (CompactLogix) : XIO Pulse_Interval_Timer.DN TON Pulse_Interval_Timer 200 0 XIC Pulse_Sequence_Counter.DN RES Pulse_Sequence_Counter XIC Pulse_Interval_Timer.DN CTU Pulse_Sequence_Counter 40 0 Each count of the Pulse_Sequence_Counter is used to trigger the start of an event, giving 40 different start 'pulses' spread out with 200ms between each. This is supposed to give a time (between the first & last count) of 8 seconds (40 x 200ms). However, because of an accumulated error due to scan time, I am actually getting around 13 seconds! The scan time of the continuous task is about 125ms. Because plc needs to scan the timer rung one more time to actually set the .DN bit), this gives an error of approx 125ms for every count, resulting a total time of 13sec (40 x (200ms + 125ms) = 13 sec) After much stuffing around, trying .TT bits instead of .DN bits, timer values, etc... I am almost out of ideas... My work-around: I put the logic into a periodic task. The error is still there, but as the period is now known & repeatable, I can then just reduce the timer preset by an amount equal to the task period, so that I end up with 8 seconds... But I would like to fix it properly! So... Is there a better way of doing this? Or a CompactLogix instruction I could use? I have had a look, but I could not find any... It would be good if i could keep the timer & counter so that I could easily deploy a fix to a few other CompactLogix systems already installed, and keep the logic standard... but at this stage I am open to anything... Cheers, Andrew W

Hi guys, Thanks for the replies. Makes sense - and explains why the I was getting the faults only when the index tag had a value of greater than 31... I am looking at changing the DINT's to an array of BOOLs... is messy but I could do it... Pre-scan.. this got me thinking, could I just modify my fault handling routine to not set an alarm for this type of fault, during pre-scan only? Is considered the lazy way out? Also, reading up on pre-scan, I noticed that the manaul states: "During prescan, the controller automatically clears any faults due to an array subscript that is beyond the range of the array (out of range)." for revision 13.0 controllers or later.. So since I am using revision 15.3, and getting fault type 4 code 83, does this mean that I shouldn't be getting a fault during pre-scan ?? (evidently not!) Cheers, Andrew W

Hi all, Apologies for the length of this post.. but I'd really appreciate some advice... I have some ST code generating a program fault (major fault), and it is driving me (CompactLogix controller, rev 15.3) Normally, none of the code is causing a fault - it verifies correctly, and does what I expect it to do... regardless if I enter it as an online edit, or download the program to the controller... However, when the PLC is switched from program to run, or the PLC powers up, I get a major fault (type 4 code 83 - out of range / data tested not in required limits). I have my controller fault routine clearing the fault and generating an alarm message, but I have disabled it, in order to find out where in the program the fault is happening. I first found the problem in one of my ST routines, made some changes that seemed to fix it, and tried to apply those changes to a second ST routine - but got inconsistent results! I also narrowed down what was happening, when trying to change the second ST routine (see notes below) - I managed to get it to fault based on the value of one my index tags... The first ST routine, original code: - The purpose of this ST routine is to clear, then check and set, some temperature deviation alarms, based on the deviation flags from a PIDE instruction. - This routine is called by a JSR from the parent routine. - Tags "Dev_Alarms_Low" & "Dev_Alarms_High" are of type DINT[2] - Tags "PID_Dev_Low_Alarms" & "PID_Dev_High_Alarms" are of type DINT[2]. One bit of each is set from a one of 32 PIDE instructions. - The tags "Dev_Alarms_Low[0]", "Dev_Alarms_High[0]", "Dev_Alarms_Low[1]", "Dev_Alarms_High[1]" are returned to the parent routine via the JSR, as DINT tags "Alarms[4]", "Alarms[6]", "Alarms[5]", "Alarms[7]". - The tag "Alarms" (not used inside the ST routine), is of type DINT[18] [color="#3366ff"](* Receive parameters from parent routine *) SBR(Number_Zones, Current_Temp, Current_SP, Dev_Alarms_Low[0], Dev_Alarms_Low[1], Dev_Alarms_High[0], Dev_Alarms_High[1] ) ;[/color] [color="#3333ff"][color="#3366ff"](* Clear alarm flags *) For Index_1 := 0 To 31 By 1 Do[/color] [color="#ff0000"][faults here][/color] [/color][color="#3366ff"] Dev_Alarms_Low[0].[Index_1] := 0 ; Dev_Alarms_Low[1].[Index_1] := 0 ; Dev_Alarms_High[0].[Index_1] := 0 ; Dev_Alarms_High[1].[Index_1] := 0 ; End_For ;[/color] [color="#3333ff"][color="#3366ff"]For Index_2 := 0 To (Number_Zones - 1) By 1 Do (* Set devs if average temp greater than 200degC *) If (Current_Temp[Index_2] > 2000) Then (* Check devs for PIDEs 1 to 32 *) If (Index_2 <= 31) Then Dev_Alarms_Low[0].[Index_2] := PID_Dev_Low_Alarms[0].[Index_2] ; Dev_Alarms_High[0].[Index_2] := PID_Dev_High_Alarms[0].[Index_2] ; (* Check devs for PIDEs 33+ *) ElsIf (Index_2 >= 32) Then[/color] [color="#ff0000"][faults here][/color] [/color][color="#3366ff"] Dev_Alarms_Low[1].[Index_2 - 32] := PID_Dev_Low_Alarms[1].[Index_2 - 32] ; Dev_Alarms_High[1].[Index_2 - 32] := PID_Dev_High_Alarms[1].[Index_2 - 32] ; End_If ; End_If ; End_For ;[/color] [color="#3366ff"](* Return parameters to parent routine *) RET(Dev_Alarms_Low[0], Dev_Alarms_Low[1], Dev_Alarms_High[0], Dev_Alarms_High[1]) ;[/color] - The controller faults at the first 'For...Do' loop (clearing alarms), and at the second 'For...Do' loop (setting alarms). - So I changed the code to this: The first ST routine, changed code: [color="#3366ff"](* Receive parameters from parent routine *) SBR(Number_Zones, Current_Temp, Current_SP, Dev_Alarms_Low[0], Dev_Alarms_Low[1], Dev_Alarms_High[0], Dev_Alarms_High[1] ) ;[/color] [color="#3366ff"](* Clear alarm flags *) Dev_Alarms_Zero_DINT := 0 ; COP(Dev_Alarms_Zero_DINT,Dev_Alarms_Low[0],31) ; COP(Dev_Alarms_Zero_DINT,Dev_Alarms_Low[1],31) ; COP(Dev_Alarms_Zero_DINT,Dev_Alarms_High[0],31) ; COP(Dev_Alarms_Zero_DINT,Dev_Alarms_High[1],31) ;[/color] [color="#3366ff"]For Index_2 := 0 To (Number_Zones - 1) By 1 Do (* Set devs if average temp greater than 200degC *) If (Current_Temp[Index_2] > 2000) Then (* Check devs for PIDEs 1 to 32 *) If (Index_2 <= 31) Then Dev_Alarms_Low[0].[Index_2] := PID_Dev_Low_Alarms[0].[Index_2] ; Dev_Alarms_High[0].[Index_2] := PID_Dev_High_Alarms[0].[Index_2] ; (* Check devs for PIDEs 33+ *) ElsIf (Index_2 >= 32) Then Index_3 := Index_2 - 32 ; Dev_Alarms_Low[1].[Index_3] := PID_Dev_Low_Alarms[1].[Index_3] ; Dev_Alarms_High[1].[Index_3] := PID_Dev_High_Alarms[1].[Index_3] ; End_If ; End_If ; End_For ;[/color] [color="#3366ff"](* Return parameters to parent routine *) RET(Dev_Alarms_Low[0], Dev_Alarms_Low[1], Dev_Alarms_High[0], Dev_Alarms_High[1]) ;[/color] - This fixed the fault for the first 'For..Do loop' (used COP instead), and seemed to fix the second 'For...Do" loop as well. All good, or so I thought. - So I was going to apply these changes to a another ST routine that works in a similar way (that was giving me the same fault with the original code).... Second ST routine, original code - The structure of the tags & the logic for this routine is similar to the first. [color="#3333ff"][color="#3366ff"]If Offset_Number_Zones < Offset_Number_TCs Then For Index_13 := Offset_Number_Zones To (Offset_Number_TCs - 1) By 1 Do If Index_13 <= 31 Then If (Not(Alarm[2].[Index_13])) And (Not(Alarm[12].[Index_13])) Then Offset_Current_Temp[Index_13] := Offset_TC_Temp[Index_13] ; Else Offset_Current_Temp[Index_13] := Offset_Average_Temp ; End_If ; ElsIf Index_13 >= 32 Then[/color] [/color][color="#ff0000"][faults here][/color] [color="#3333ff"][color="#3366ff"] If (Not(Alarm[3].[Index_13 - 32])) And (Not(Alarm[13].[Index_13 - 32])) Then Offset_Current_Temp[Index_13] := Offset_TC_Temp[Index_13] ; Else Offset_Current_Temp[Index_13] := Offset_Average_Temp ; End_If ; End_If ; End_For ; End_If ;[/color] [/color] - So I made the same changes as I did for the first ST routine: Second ST routine, changed code: [color="#3366ff"]If Offset_Number_Zones < Offset_Number_TCs Then For Index_13 := Offset_Number_Zones To (Offset_Number_TCs - 1) By 1 Do If Index_13 <= 31 Then [color="#3333ff"] [/color][color="#ff0000"][faults here!!][/color] If (Index_13 < 31) And (Not(Alarm[2].[Index_13])) And (Not(Alarm[12].[Index_13])) Then Offset_Current_Temp[Index_13] := Offset_TC_Temp[Index_13] ; Else Offset_Current_Temp[Index_13] := Offset_Average_Temp ; End_If ; ElsIf Index_13 >= 32 Then Index_26 := (Index_13 - 32) ; If (Index_26 < 31) And (Not(Alarm[3].[Index_26])) And (Not(Alarm[13].[Index_26])) Then Offset_Current_Temp[Index_13] := Offset_TC_Temp[Index_13] ; Else Offset_Current_Temp[Index_13] := Offset_Average_Temp ; End_If ; End_If ; End_For ; End_If ; [/color] - I was expecting this fix the fault... but instead, I was getting a fault in the first "If... Then' loop, rather than the second !! - I tried setting the tag "Index_13" prior to the 'For..Do' loop, but that did not work. - I noticed that the value of the tag "Index_13" was always 33 after the routine was executed. If I then changed the PLC from Run to Program and back to Run, the controller would fault. However, if I first manually set tag "Index_13" to zero (type in a value of zero in the tag monitoring / editing window), then changed the controller to Run mode, it would not fault!! So... I can't find what is wrong. Is there something fundamental that I am doing wrong? The easy fix is not to set any alarms in my program for this fault type & code.. but I don't like that, I'd like to fix it properly... Can anyone help me ?! Cheers, Andrew W