Dear Community User! We have started the migration process.
This community is now in READ ONLY mode.
Read more: Important information on the platform change.

cancel
Showing results for 
Search instead for 
Did you mean: 
SOLVED

Issues with entity names

Issues with entity names

alink
New Contributor

Hello,

again there is a bad issue with entities.

Everything worked well till there was an error stop suddenly.

Issue at fbAIL_ECATRead

It's from IL_ECATSoeRead

alink_0-1682321765034.png

alink_1-1682321815029.png

There are more used (fbBIL_, fbCIL_, fbDIL_ )and the others have no issue, so the error message of PLC Engineering is NONSENSE!

alink_2-1682321859060.png

 

After renaming to fbEIL_ECATRead everything works -- no issues!

alink_3-1682321952219.png

alink_4-1682321979700.png

Going back to the name fbAIL_ECATRead error is again!

Such sudden errors are annoying with no sense.

No way to solve such error. No clearing or something helps.

Just a reset of PLC each time!

At the moment it's just a testing and developing system but there is no trust to make a product for customers with such problems.

 

Hopefully there is solution for this damned problem.

There is no fun to rename functions everyday just to get it working.

ctrlX PLC 1.18.1 is used

alink_0-1682327277749.png

It seems to have some analogy to this post:

Variable loosing its status (boschrexroth.com)

14 REPLIES 14

alink
New Contributor

And now, even with the other name fbEIL_ECATRead, the same again:

alink_0-1682334265049.png

As soon as the Ethercat Read function is executed system stops with error stop.

Sorry, don't see anything wrong. First it works, than, suddenly, it stops.

Maybe one thing: it happends after a log in / online-change and PLCengineering report:

An application is running....

Now, with the name fbFIL_ECAT it is running....

alink_1-1682334703082.png

I don't hope to reach fbZIL_ECATRead

 

CodeShepherd
Community Moderator
Community Moderator

The message coming up makes totally sense as you get an error inside the function "IL_ECATRead" inside a compiled library and the ctrlX PLC Engineering cannot debug into it as there is simply no code that can be shown. That's why you got asked if you like to search for an "original" or open library to see the code.

As you hinted that you are doing online changes/logins I guess the pointers used in the function are messed up because the internal memory get rearranged by your code changes. creating new function blocks simply takes a new instantiated pointer that works as long the memory area stays the same.

So beware that especially pointers can get invalid by online changes. Could you do a full login (no online change) and see if everything is working again in your "older" read functions?

Login with download, after going back to the old name there is a error-stop again.

When getting this message then the issue occurs.

alink_0-1682346366479.png

Even when doing a clearence and clear all, it's not possible to get it back to work again with original name.

Just with another, new name. And just for this one, with other EatherCat functions is no problem till now.

When doing a download, it doesn't matter if this function is in use or not at the moment. But when it then is used then error-stop.

 

CodeShepherd
Community Moderator
Community Moderator

The message to overwrite the application is fine for a download as you have to be aware that the old application will get deleted. Do you click "Ja" and then its loaded?

In another screenshots in line 22 you write "ADR('ethercatmaster')" this could cause such pointer problems as you can see the address is changing. I am not sure how the compiler is working with this. Could you try "ADR(MyStringVariable)" and assign the name of your master to it?

Could you add a screenshot of the complete Engineering tool when error is occurring so we can also see the error itself?
For a better possibility for us to have a look into your problem we would need a system report including your app data (active configuration)

Yes, with"ja" it is loaded but with error. So if old application is deleted than there shouldn't be an issue with old things....

But what ever, I tried it the way with setting a var with the name.

At the moment, even with an old, corrupted, not working name of the E-Cat-function, it does work now.

Instead of setting MasterName inside of function it is written into string-var outside.

alink_0-1682435584356.png

I will take some care if issue comes again.

Thanks a lot till now👍

Short question:

Is it a better way of coding using variables instead of direct expressions in FBs?

If this could cause issues than good to know to avoid problems in future.

I don't understand what issue is:

Now, error stop again as soon as execute is set to true - ....bang...stop

alink_0-1682511856866.png

Means, when in line 23:

alink_1-1682511933792.png

CtrlX PLC looks like this, no further error description

alink_3-1682512498705.png

 

The use of that funciton is:

On a webVisu, there is a "Diagnose"-page. Is this page opened then this program is active. Then the function to read drive paramenter P-0-0190 is started. But with the first call it stops. Suddenly. Currently I was just doing some graphical modifications on visu-pages. Logged in/out several times to see the result. Then, suddenly, no reason, bang - stop - 

In ctrlX Core:

alink_2-1682512302727.png

alink_4-1682512588888.png

 

Attached is a backup of configuration

 

 

 

alink
New Contributor

Now, did another test:

Because a WebVisu-page before there is a ECat reading where to read out drive messages.

This side was closed and another without any ECat reading was open. In PLC engineering, with test var, my "diagnose" page was triggered.

--bang-- error stop!

So there is no competitive action with this FB.

If this FB is comment out than it works.

Even if all ECat readings FB are running simultaneously, means 4 in two POUs.

alink_0-1682583043663.png

The only difference between the one which is not working/has issues to the others:

The 'problem FB' should read out a P-parameter of drive while all others read a S-Parameter, nothing else.

With some other coding and another IDN (S-0-0384) the FB does nothing anymore, it is standing or what ever:

The FB is renamed from fbEIL_CATRead to fbAIL_ECATRead.

No Done, no Error. Execute stays TRUE, no readings, nothing. But no error at the moment.

Now the same S-Parameter as in next ECATReading.

alink_1-1682590098703.png

And with P-0-0190 the same, FB is not working, while the others are OK

alink_2-1682590277676.png

 

It's really strange...

CodeShepherd
Community Moderator
Community Moderator
  • I normally use variables connected to functionblocks, as changes to the value can be made quite fast without recompiling and login. This especially useful while testing phase.
  • If a function is used on an input like ADR or SIZEOF also I always use variables. But sometimes constants if the input is a standard type.
  • Another aspect is, that many values are needed at several positions in the program and using a variable gives a single point of code changes. That is much faster and fail-safe.
  • Using variables also makes you more independent on compiler versions and settings. As it is depending on them how constants are handled.
  • At last looking to your code I would suggest to always put your function blocks outside of any if/case/while/for structures, so they will get called in each cycle and not only as long as if statement is true. Only use the in/outputs inside. This will only cost quite less more performance but is also way more fail and process safe. Your "hanging" topic will be solved by this.

In my tests at my machine (version 1.12) I used the read parameter example out of the CXA_EtherCat library and it worked:

ctrlX PCL Engineering read P-0-0190ctrlX PCL Engineering read P-0-0190

Interesting, with a manual Excecute:

POU is called but ECATRead kept in Execute :=FALSE, but ValueAdr has a value. It is toggeling between 16#7F1C77EF00 (what ever this is) and 16#0

alink_0-1682603556264.png

alink_1-1682603636609.png

If Execute := TRUE the same:

ValueAdr is toggles between 16#7F1C77EF00 and 16#0

alink_2-1682603810964.png

But now, even with a new name of FB it doesn't work:

alink_3-1682604258679.png

And with this kind of coding:

It doesn't work as well

alink_0-1682605717995.png

 

But for P-0-0190 there should be this value:

alink_4-1682604296293.png

I am confused:

With my old coding there is an error stop, unexpected and without any reason.

If it this is happened, than the name of FB can't be used a second time. The name is more or less 'damaged'. If doing a complete download, a clear all, a restart of ctrlX, a shut off and on, nothing helps. With this name the FB is dead.

A new name has to be given till a next, unexpected stop. Then the same procedure.

 

With another style of coding ther is no stop but the FB is not working, No Done, Error or value or anything. If going step by step, FB is getting parameters correctly.

Don't know what to do now.

With another writing of code there is no stop but FB doesn't give any result, value.

 

 

CodeShepherd
Community Moderator
Community Moderator

I cannot explain what exactly happened in your first coding but will try to find some information.

In your last screenshot I cannot see where the function block call is located. Line 8 in my version.

Further more in your line 61 you will always overwrite your visualization variable with "12345". So even after a successful read the value will be overwritten again. You could add this to the declaration part. Then it will only be written once while boot up.

We could also have a live session. Just write me a private message with your contact data and a time proposal.

I'm terrible sorry, my mistake, forgot to the call of FB.

Now, with call:

Execute is FALSE.

FB is called line 60 => STOP

alink_0-1682667594045.png

 

CodeShepherd
Community Moderator
Community Moderator

Problem was fixed in a live meeting.

Icon--AD-black-48x48Icon--address-consumer-data-black-48x48Icon--appointment-black-48x48Icon--back-left-black-48x48Icon--calendar-black-48x48Icon--center-alignedIcon--Checkbox-checkIcon--clock-black-48x48Icon--close-black-48x48Icon--compare-black-48x48Icon--confirmation-black-48x48Icon--dealer-details-black-48x48Icon--delete-black-48x48Icon--delivery-black-48x48Icon--down-black-48x48Icon--download-black-48x48Ic-OverlayAlertIcon--externallink-black-48x48Icon-Filledforward-right_adjustedIcon--grid-view-black-48x48IC_gd_Check-Circle170821_Icons_Community170823_Bosch_Icons170823_Bosch_Icons170821_Icons_CommunityIC-logout170821_Icons_Community170825_Bosch_Icons170821_Icons_CommunityIC-shopping-cart2170821_Icons_CommunityIC-upIC_UserIcon--imageIcon--info-i-black-48x48Icon--left-alignedIcon--Less-minimize-black-48x48Icon-FilledIcon--List-Check-grennIcon--List-Check-blackIcon--List-Cross-blackIcon--list-view-mobile-black-48x48Icon--list-view-black-48x48Icon--More-Maximize-black-48x48Icon--my-product-black-48x48Icon--newsletter-black-48x48Icon--payment-black-48x48Icon--print-black-48x48Icon--promotion-black-48x48Icon--registration-black-48x48Icon--Reset-black-48x48Icon--right-alignedshare-circle1Icon--share-black-48x48Icon--shopping-bag-black-48x48Icon-shopping-cartIcon--start-play-black-48x48Icon--store-locator-black-48x48Ic-OverlayAlertIcon--summary-black-48x48tumblrIcon-FilledvineIc-OverlayAlertwhishlist