S7 Rewire FB Error

I am trying to rewire an FB that I created, then copied. I have designed the systems in a redundant fashion so that they are identical in structure, just different I/O words.

Error Text:
E Ln 000001 Col 001: An illegal component access
follows the symbol I50.
E Ln 000001 Col 001: Variable I50 does not match a
declaration and is not I50 in the symbol table.
E Ln 000001 Col 001: An illegal component access
follows the symbol I63.
E Ln 000001 Col 001: Variable I63 does not match a
declaration and is not I63 in the symbol table.

Click to expand...

After it was completed I copied it and now I am trying to rewire it. I get an error regardless of what format I try. I used this on a different FB last week and it worked. I entered IW##'s and it processed the file without effort. I have even tried just a single discrete input I50.0 I 63.0 and still the same error.

Any ideas? Below is a few of the formats that I tried with no luck.
I made sure that the hardware was included for all of the I/O in these files, and it has all been checked for consistencies and compiled with no errors.

If you click on one of the rows in red, what text appears in the Note field?

I have used the rewire functions once or twice.
But I cannot really recommend it.
You cannot for example export or import the rewiring table.

I think it is much better to set the address priority to symbolic and simply edit the absolute adresses in the symbol editor.
You can export and import to/from excel, where you can do a heap of tricks. Much better than editing a symbol or adress one by one.
When you do a check block consistency, then all the symbolic accesses will be updated.

The rewire function was neat in STEP5, but I think that it is a bit of a leftover from STEP5 that hasnt been implemented very well in STEP7.

Thank you for the info and tips Jesper. That was going to be my work-around today. I did most of the symbols that i added through a DIF file in a spreadsheet. The I/O has simple symbols on them that match thier I/O numbers. I'll redo them today and be on my way.

Just came to think about this:
Why even access i/o directly within an FB ?
And the rewiring business seems to me is because you are actually reusing the same code for differing i/o.
The only time where you should access an i/o address within an FB is when the i/o must have some global function ("pilot_voltage_relay_on" for example), and in that case you do not need to change it for multiple accesses.

L D,

It just says Syntax Error. If I hit OK it errors and the log file shows the above text.

rikcando said:

The I/O has simple symbols on them that match thier I/O numbers.

Click to expand...

Never do like that again please.
I am guessing you used to program S5, yes ?

And, if you are changing the symbols from just a mirror of the absolute adresses to something more symbolic, then set address priority to "absolute".
When you have finished editing the symbols, and have done a block consistency check, and have made a backup, THEN switch to "symbolic" adress priority.

Jesper,

I have two identical dunnage conveyor systems, one using IB(QB)50 through 60, the other uses IB(QB)63 through 73. The logic in the FB does all of the decision making on when two run each motor and lift. I need to look at the I/O to make these decisions and to start/stop the motors.

I actually have two different sets of conveyor systems which each contain two identical conveyors and a cross-over between them. I wrote the program for the first one of the first set and used the rewire feature to change the I/O to its twin. I am now doing the second set and the rewire feature does not work.

No, I did not use Step 5. Further, this is my first Step 7 program development, although I have had the oppurtunity to debug a couple of really small applications.

As I did the electrical and pneumatic designs another person started the programming. I was handed what he had done and asked to finish it. In my opinion he did very little correctly. I have had to completely rewrite most of the networks. I have very little time to complete this as most of the equipment has already been shipped and I am expected to be in-plant sometime in the next couple of weeks. I am tying to save time by leaving things like fixing symbols until after I have completed the logic. I still have two robot and two camera interfaces to complete so symbols took a low priority.

I can assure you that I would never have created this symbol table.

The only time where you should access an i/o address within an FB is when the i/o must have some global function

Click to expand...

May I ask why? Should I have my logic for the I/O within an OB ? I must access the I/O somewhere. I do not understand.

Then maybe the previous programmer used to program S5. In S5 symbols were limted to 8 characters (or was it 6 ? I dont remember now). And that caused most programmers to just create symbols that mirrored the i/o addresses, i.e. "q2.3" for the address Q2.3.

The purpose of FBs is to be able to separate the code from the asociated data. The data may be what is passed to/from the code (via the FBs IO pins), or the memory that the FB uses internally (the STAT area of the declaration table).
In this way you can create standardised reusable code.

The way you describe it, you could probably just as well have been using FCs in stead of FBs.

You can certainly do as you do now. Then it is more like classical non-reusable code, i.e. each object has a specially adapted FC or FB programmed for it. And if you are pressed for time, then maybe it is the smartest to do for now.

I had considered making reusable code for the conveyors and pallet trafficing, applying the IWs, QWs, and DBs to the IN/OUT but I felt this would have made it more complicated than it needed to be. That, and I was not certain how to address the IW(QW) bits individually within the FB in a legible manner once they got there and I did not have time to get past that learning curve. Hopefully I can pick this up for my next turn at bat.

(This is probably not going to go over well, but it is just my opinion)
I use the reusable code philosphy whenever possible is my C, C#, .Net, or whatever other hidden language programming I may be tasked with. This is in the case where the programmer is the only person expected to be able to follow it. When programming in PLCs I tend not to use it as much. I have worked with numerous maintenance electricians that have some difficulties following this method of programming. I have found that it is easier for the end users to read, and therefore troubleshoot when the program is more straight forward. This helps to reduce the service calls and allows me more time for the next project.

For pallet trafficking I feel the end user will benefit from the laid out format over the years of use more so than they would from a more memory efficient formatted program filled with reusable code.

One auto manufacturer contracted me to rewrite some logic for them as what they had was considered not serviceable. (Actually, I have done this for two different majot auto manufacturers.) I wrote the logic with using as little internal memory bits as possible. Yes, it took a lot longer to write, and too more memory within the controller. One instance was a 36 station carousel which we debugged over a single week end. Whenever there was an issue the electrician had all of the I/O was right there in front of them and was not required to perform any cross references to find the cause of the issue. I have never had a return service call for that equipment.

In this area, Step 7 programmers are rare and in high demand as this is not used here often. Most electricians are trained on Rockwell style software. This is something that I must keep in mind while developing the software. The end users ability to take the software and maintain it is more important to me than efficient memory allocation.

With that said, I want to state that I wish I knew enough about Step 7 to be able to better develop such reusable code. I too have been trained on Rockwell, Modicon, and other such PLCs. Step 7 is a more complicated, yet much more versatile application development environment and I truly wish I had time to study it.