2n2907

Hi, Sorry that this is a old topic but I was having the same problem and this was the second Google result. I am connecting a Unistream to Web Studio (Now AVEVA Edge). I had the same error as above so I went to the driver page and there was no error 28. Then went and found the generic driver help and it listed the Error 28 as Framing. So I then got to the Standard Driver Sheets help page and at the bottom it said: Each Standard Driver Sheet can have up to 4096 rows. However, the Read Trigger, Enable Read When Idle, and Write Trigger commands attempt to communicate the entire block of addresses that is configured in the sheet, so if the block of addresses is larger than the maximum block size that is supported by the driver protocol, then you will receive a communication error (e.g., "invalid block size") during run time. Therefore, the maximum block size imposes a practical limit on the number of rows in the sheet, and that limit varies by driver. For more information, please refer to the driver documentation for your selected driver. So the sheet can hold 4096 rows, but Modbus driver has a max of 255 bytes. Changed my sheet to be below the 255 Byte limit and it worked. This limit is not talked about on the main driver help page so it was easy to over look. Hope this helps someone, though I hope that you are not still working on the problem 4 years later. 2N2907

RickL, To start this I just to let you know my background so you know were this is coming from. I have been programming PLCs for 9 years. I started with Unitronics and have used other brands. I also have experience with microcontrollers and other small electronics. So these comments are things that I have had to learn the hard way on jobs. So let's start from the requirement that was listed: "The normally idle, stand alone, self-extrication PLC is will be in "hot-standby" mode with battery back-up operation. I'll need to establish a communication link between these two PLCs. I'll need more than just a "heart beat" failure indication of the main PLC controller, thinking to possibly emulate a "catch/throw" error paradigm with-in the main controller to the cause of the controller/peripheral failure. Here the extrication PLC would weigh the best course of action." That is an outline of an idea. There is not enough information to start trying to figure out what your question is. What are you asking/looking for from this thread? Starting with the elephant in the thread, what is the difference between this and a set of manual control overrides after the main PLC fails? Now to the talk about the outline as if it was a good idea that I would have to help work on : The communication between the two PLCs is a big part of the scope that was not talked about in detail. How will the two PLCs communicate? The hardware Layer? The protocol Layer? Are you going to write your own protocol or use one the PLC supports? Have you looked at the different protocols that the PLC supports and picked which one that you are looking at using? What data do you want to move? ML,MB,DW,MI,MF When you say "catch/throw" is that from the C or java error handling? In PLCs you can only send integers or coils directly between the two PLCs. (there can be ascii text stored in the integers) What are you thinking of sending that the second PLC needs to know from the first? Are you looking to make the main PLC send a error to the second PLC or talk all the time? How fast is the send/receive rate between the two PLCs? After talking about PLC communication now is the extrication PLC Hardware: Have you looked at what goes into amusement park rides for PLC and IO? They are dual PLC Processors, dual PLC IO cards, dual field sensors and dual outputs. If your first thought is that an elevator is not that complicated as the ride, then as my PLC teacher hammered into me "The devil is in the details. You have to think it through". So what is the second PLC going to get the data from? Will it have its own PLC Inputs? Will it have safety rated inputs? Will it have its own secondary sensors? Will it have its own Position Sensor? Will it have its own outputs? Will it have override outputs to block the main PLC? What keeps the second PLC from going bad? Are the two different PLCs in the same cabinet? Do they have independent 24V power supplies? Are there sensors and IO from a different power supply? Will it be connected to the fire alarm? What to do for every different error that can happen? How to display the errors when they do not agree? Who will win between the two controllers? The error checking: The scariest thing that a customer can say to me is "Just have the PLC figure it out what is right". There is a ton of work going into error checking and knowing what is right to the process. Just to know if there is an error is hard even with two sensors, what sensor is right and what sensor is wrong. Again who will win between the two controllers? I can count on one hand the number of times the PLC stopped working on a machine that was not damaged by the operators or it's environment. The PLC hardware error that you are looking to fix will be small. There is a lot of thought that has to go into what the error state is going to do.. How will this be displayed to the end user, staff? What advantage will there be over a set of manual controls? What about equipment failure for non PLC parts? What about Fire Service? The posted description is confusing: "hot-standby" "extrication PLC would weigh the best course of action" So the second PLC will not drive the elevator but to the safety floor, then it is more of a watchdog PLC not a hot-standby. If you think that I am trying to be dismissive just think what you have given in details in the topic. This is what I would ask the customer if I was trying to make this work for real. The simplest part of the project is getting the two PLCs to talk, the hard part is what to say. If you think that they are both simple and I am wrong then I go ahead and ignore what I had to say. Have you looked at the enclouded example programs? They are a great way to learn about and see how the functions work. They may be on other PLCs but I have used them in the past to see how to make communication work. The pump program you are working on is a good way to start learning about PLCs. There is a place to get your hands dirty and just see what you can do. If you are looking for someone to post a program for communication between two PLCs with error checking to help you getting started, then you should consider that this project is beyond the scope of what you can handle. The people with knowledge gained by programming for years have suggested that this is beyond what a person's third project should be. This is not gatekeeping, this is explaining what we have learned from our experience in programing. I know that by saying that you are going to take that as a challenge. That I can not help, I am just trying to give an objective answer to what you have posted. When the other people on the forum are saying this is "outside the realm of typical PLC control" is because there are controllers that are specially built for the job. They have been tested and are known to work and have been certified. Anything with a dedicated controller can be run by a PLC, but would you want to use a sledgehammer to crack a walnut? As much as I enjoy talking about feeding mayonnaise to live tuna fish, there are some things that would be better spent programming time on.