Lars_01

We got the problem with the performance solved. It turned out that one of our switches was the reason for this. The strange part was that I tried with plugging the License server and my computer directly to our router. The faulty switch was on the network, but data should not need to go via the switch, and we still had the issues with performance. When we completley replaced the switch, the perfomance got good. The only thing we noticed was the performance of the license server, however after the switch was replaced ping times to internet was reduced and a minimal lag (0.5s...) when opening a network share for the first time disapeared, so maybe there was something more...

That is pretty much the same experience that I had with the support, it ended with I can't really help you to get it any better... I also tried with and without 27000@ and without it I got no connection at all. But for me it seems to be related to the network, since it works fine on another network... Could be some setting somewhere that would slow it down, but I really can't figure out what it can be.

Hi, I wonder if anyone experienced problems with performance on factory talk activation server. I have a computer that I use as activation server, when setting it up at my home office and accessing the activations from a client computer on the same network the refresh rate of the activations is fast less than 5 seconds to get all the licenses. After that the server was moved to the work network and I tried to access the activations (From the work network) and it took over 2 minutes to refresh the activations. So then I figured that something had happened to the comptuers and tried to isolate the server and a client on a separate router, to test it out, and the speed was back to normal again. But as soon as it is connected to the work network it is slow. Does anyone know of any settings that should be done in the router / switches to speed up connections? I connect to the activation server with IP and specify port number to use (27000@xxx.xxx.xxx.xxx)

Hi, I have some issues with my concurrent activations and wonder if anyone seen anything similar I have the activations on a Windows 2003 Server and running FactoryTalk Activation Manager 3.30 (I tried the old Activation Server, but had the same result) When borrowing activations we usually connect using VPN to the server, the problem is that it takes a couple of minutes for the activations to show up on the client. I have been waiting for over 5minutes for 8 activations to show up. And sometimes they do not show up at all. The VPN is connecting to a Router We have tried different routers and different VPN clients and different VPN types. I have only connected to the server without VPN once and I actually think that it took almost as much time to update the activations that time to (But it was once when I was testing some other things, so I do not recall exactly) Does anyone have any Ideas of what the problem could be?

Now I think that finally we almost have provided a answer to a very easy question... I have always used produce and consume. To see that the data is transfering I have been using watch dogs, and sent it both ways always counting up with one and then a reset when it reaches some high value. I belive that you can also monitor the status of a consumed tag, but it is not as simple, (I do not think you can monitor the producer) As far as all the status bits and being able to see that you missed a message.. and all that Well, yes you do have all the status bits and can see if you got error on a message, but what you are missing is that it can take a couple of scans to complete a message instruction, so it might take half a second before you realize it or even more (I do not know the exact numbers, depends on message size and CPU load and stuff aswell as the setup of the message) So with all this in some cases it might be faster to use a watch dog on a produced tag. And even with messages the way I have been using them is that I retry to send the message a couple (Usually 3) times before I set any alarm... Using only the status tags on the message, you only get to know if anything went wrong in the PLC with the message, by sending a watchdog back and forth, you can alarm in both PLCs. But in the end it depends on the requirements of the application, on what can can be accepted or not... And a side note RPI is not the polling rate of an I/O card. Clx Processors does not poll data, it configures the card and then the card sends the data automatically with the RPI time...

The best place to get information about rockwell is their literature library and their knowledge base. You can find all sorts of facts there. Regarding connections, I know there is a good manual for ethernet that have detailed information about counting connections, but I could not find it now. If you have a techConnect contract you can check on the knowledge base, I found this document quite fast: http://rockwellautomation.custhelp.com/app/answers/detail/a_id/56682/kw/count%20connections Regarding RPI, you are more or less right there. It stands for Requested Package interval or something similar, and it tells I/O cards and other data producing devices how often it should send data. So if you set it to 20 for a device it will send data avery 20mS. Just a side note, that does not mean that you get new data every 20ms, other factors affect it such as Network delays delay due to scan times and such things.

The cost saving for Compact logix can actually be quite large, depending on the type of sytem that you are using. But you need to be carefull not to save too much. If you have a plant were you only use compactlogix and only program in ladder (And can deal without some other functions) you can buy a cheaper version of RsLogix 5000 (And there are quite a lot to save there, specially if you need a couple of licenses). If the process is divided up in modules or smaller sections with many processors rather than a main PLC, it is probably wiser to go with the compactlogix. What you were talking about sounded like 2 CIP stations and a level indicator / Controller of a tank on one controller. To me that sounds like CompactLogix, but it is hard to be certain about it with this limited amount of information. If there is a main plant PLC somewhere that should probably be a ControlLogix... But the tricky part is to not try to save too much, then it will be more expensive in the end... I have been there and it is hard to get out of it...

A few comments, maybe not so important, but 1. CIP I was under the impression that it was "Common Industrial Protocoll" 2. A message instruction is never Determenistic as far as I know. While a produce/Consumed tag can be Determenistic if it is used on ControlNet (No other Rockwell network is 100% determenistic) 3. A message instruction is not scheduled, sure you can send it with a certain interval, but I would not say that it is scheduled. If anything is scheduled it is Produce Consume, since you do put a RPI time on them. 4. I think that the Produced consumed data actually is sent by the I/O processor in ControlLogix, so it is independent of the Timeslice. While messages I think needs some overhead taken from the timeslice (I could be wrong but it is my understanding) If you are communicating with 2 Logix5000 systems (ControlLogix, CompactLogix or even the old Flex Logix) Use Produce Consume. Keep down the amount of produced consumed tag as much as possible, by combining data in UDT's and send. Each tag takes up connections and you have a limited amount of connections. When you create a UDT that you want to send you should copy it to the project where you want to receive the data also. There are a few reasons that messages could be better, if you want to keep down the amount of packages/Second a message could be better since it is not sent automatically... If you are communicating between a 5000 system and something else, it is easiest to do it with messages, though there are ways to use produce consume on SLC and PLC 5 systems also, but it is not as easy.

I realize that I made a misstake... My question should actually be for the analog Output, 1734-OE4C... For the analog input it is even according to the manual possible to use the TB3 In anycase, it did not really answer my question. Does anyone have any experience with the TB3 terminal and 1734-OE4C?

I wonder if anyone knows if it is possible to use 1734-TB3 with the 1734-OE4C. After what I can see in the Selection guide it is not possible, but I do not understand exactly why. According to the installation guide channel 0 can only use pin 4 as common and the other 3 channels can only use pin 5 as common. This sounds strange to me, common should be common? So if they are shorted as in the TB3, does it really matter? Edit, wrote wrong first, should not be the IE4C but the OE4C... Sorry for the confusion