Welcome to the new Schneider Electric Community

It's your place to connect with experts and peers, get continuous support, and share knowledge.

  • Explore the new navigation for even easier access to your community.
  • Bookmark and use our new, easy-to-remember address (community.se.com).
  • Get ready for more content and an improved experience.

Contact SchneiderCommunity.Support@se.com if you have any questions.

Close
Invite a Co-worker
Send a co-worker an invite to the Exchange portal.Just enter their email address and we’ll connect them to register. After joining, they will belong to the same company.
Send Invite Cancel
84755members
354187posts

String in EEPROM

Machine Automation Forum

A forum addressing machine automation solutions for the complete machine lifecycle. Including offers like Machine Advisor, Modicon PLC/PacDrive, Lexium or Preventa. Discuss and share knowledge on offers relating to cloud-based service platforms, machine localization and monitoring, industrial operations control, motion products as well as safety function!

Solved
otrotabi
Lieutenant
Lieutenant
0 Likes
11
508

String in EEPROM

Is it possible to save a STRING[4] in EEPROM ?.

 

I figure I could use some self defined table and assign A = 0001 B = 0010 C = 0011 etc... so I think I could save at least 5 chars (letters) in a UDINT.

 

I have downloaded the StrLib but it only works from date/numbers to str but not the other way around.

 

Of course this would not be very helpfull if changing it from HMI would not be possible anyway, so that wouild be my second question.

 

 


Accepted Solutions
FedericoM
Lieutenant Lieutenant
Lieutenant
0 Likes
10
501

Re: String in EEPROM

Hi,

 

target M171O doesn't allow to manage strings into EEprom (it is allowed with M172 which has also dedicated operators to manage them in the operator and standard blocks).

 

 
 

A workaround to copy an UDINT EEprom into a String is the following (tested only in simulation):

 

PROGRAM main

VAR
string1 : STRING[ 4 ];
ptrUDINT1 : @UDINT;
ptrUDINT2 : @UDINT;
ptrBYTE : @BYTE;
END_VAR

 

ptrUDINT1 := ADR(str4);

ptrUDINT2 := ADR(string1);

@ptrUDINT2 := @ptrUDINT1;

ptrBYTE := ptrUDINT2+4;
@ptrBYTE := 0; // End of string

 

Where str4 is an EEprom UDINT

A string of 4 chars is made of 5bytes, so you must be sure that at least the fifth byte is 0

See Answer In Context

Tags (1)
11 Replies 11
FedericoM
Lieutenant Lieutenant
Lieutenant
0 Likes
10
502

Re: String in EEPROM

Hi,

 

target M171O doesn't allow to manage strings into EEprom (it is allowed with M172 which has also dedicated operators to manage them in the operator and standard blocks).

 

 
 

A workaround to copy an UDINT EEprom into a String is the following (tested only in simulation):

 

PROGRAM main

VAR
string1 : STRING[ 4 ];
ptrUDINT1 : @UDINT;
ptrUDINT2 : @UDINT;
ptrBYTE : @BYTE;
END_VAR

 

ptrUDINT1 := ADR(str4);

ptrUDINT2 := ADR(string1);

@ptrUDINT2 := @ptrUDINT1;

ptrBYTE := ptrUDINT2+4;
@ptrBYTE := 0; // End of string

 

Where str4 is an EEprom UDINT

A string of 4 chars is made of 5bytes, so you must be sure that at least the fifth byte is 0

Tags (1)
otrotabi
Lieutenant
Lieutenant
0 Likes
0
473

Re: String in EEPROM

Thank you.

 

I only tried in simulation so far but next week I will try it on a real target.

 

I must confess I still need more time than I would like to when pointers are involved 🤔 but hopefully I will get better !

 

 

Tags (1)
otrotabi
Lieutenant
Lieutenant
0 Likes
8
453

Re: String in EEPROM

The purpose of this topic is to be able to show an alarm "short name" which is descriptive to the installer an needs no error table list (hopefully).For example, when alarm number  9 occurs instead of ER09,  ´CMOT´ is shown on the display. Hopefully next time anyone asks what CMOT means I would be able to troubleshoot a compressor motor thermal overload alarm without looking at the alarm list. Having it set at EEPROM instead of inside the program could ideally give the installer the possibility to assign it a different "shortname", maybe ´THOL´ for example.

 

So, basically I use the OverwriteLocalDisplay function to display this shortname at the display when a new alarm happens and I have created a function which translates an alarm code into a 4 char STRING

 

FUNCTION AlarmShortName: STRING[4]

VAR_INPUT
	usiCode : USINT;
END_VAR

AlarmShortName := '';

CASE usiCode OF
	0: AlarmShortName := ' OFF';
	1: AlarmShortName := 'CRES';
	2: AlarmShortName := 'FLRS';
	3: AlarmShortName := 'PMOT';
	4: AlarmShortName := 'PHAS';
	5: AlarmShortName := 'FLOU';
	6: AlarmShortName := 'PAL3';
	7: AlarmShortName := 'PHPS';
	8: AlarmShortName := 'PIPS';
	9:	AlarmShortName := 'CMOT';
	10:	AlarmShortName := 'OILP';
	11:	AlarmShortName := 'HPSU';
	12:	AlarmShortName := 'LPSU';
	13:	AlarmShortName :='EMER';
	14:	AlarmShortName :='EMER';
	15:	AlarmShortName :='HPAN';
	16:	AlarmShortName :='LPAN';
	17:	AlarmShortName :='INPS';
	18:	AlarmShortName :='OUTS';
	19:	AlarmShortName :='LIQS';
	20:	AlarmShortName :='TANS';
	21:	AlarmShortName :='AHPS';
	22:	AlarmShortName :='ANLS';
	23:	AlarmShortName :='THIG';
	24:	AlarmShortName :='TLOU';
	25:	AlarmShortName :='TDLO';
	26:	AlarmShortName :='TDHI';
	27:	AlarmShortName :='FAN1';
	28:	AlarmShortName :='FAN2';
	29:	AlarmShortName :='FAN3';
	30:	AlarmShortName :='FLOS';

END_CASE;

 

And display the alarm like this:

 

usiret:=OverwriteLocalDisplay(3,AlarmShortName(AlarmCode),AlarmCode,0,0,0);

 

However, this works fine only in simulation. When used on a real target, retrieving the string from the function for some reason it does not, in one case it only affects the first letter, but on some other use I get only "AAAA" as a string on the display.

 

I also tried:

 

AlarmString :=  AlarmShortName(AlarmCode);

usiret:=OverwriteLocalDisplay(3,AlarmString,AlarmCode,0,0,0);

 

but I get the same result. 

 

By using the real time debugger I am able to see that actually what is returned from the function is a wrong string, the OverwriteLocalDisplay function is not to blame.

 

The workaround for this is to place the CASE structure right before calling the OverwriteLocalDisplay function, but since I use it in a couple of places in the project, there´s always the possibility of mistakenly writing something different in each place.

 

Any idea of why ? Is it a limitation of the PLC ? I am using a TM171OF22R.

 

 

 

 

 

Tags (1)
FedericoM
Lieutenant Lieutenant
Lieutenant
0 Likes
7
367

Re: String in EEPROM

Hi,

 

I've found the workaround shown in the attached project...

Attachments
Tags (1)
otrotabi
Lieutenant
Lieutenant
0 Likes
6
332

Re: String in EEPROM

Thank you for your feedback.

 

The drawback for this approach seems to be memory usage. I must admit my ideal program may not fit well inside TM171 memory limits and may be better solved with TM172 but anyway we still need to develop a "cheap" solution for some small machines. 

 

When I add more global vars I sometimes get the message "Auto vars space exhausted" while saving them on EEPROM would not, at least for a reasonable number of alarms.

 

I know you told me accesing the definition as stored within the Alarm menu is not possible, but If you don´t mind my asking I would like to know why. Are they stored in memory locations not accesible ? Or simply unkown because of the way the compiler stores them ?

 

Although the alarm system as it is implemented does provide a certain solution, it does impose a basic degree of knowledge regarding the way the "AL" menu is accesed. On most number of cases, the kind of systems we build and sell do not have a maintenance guide around 24/7 but they must work 24/7.  This is why I care about the fact that the current alarm is shown on the display because many times it might mean solving the issue by phone instead of sending someone to the system location.

 

 

 

Tags (1)
FedericoM
Lieutenant Lieutenant
Lieutenant
0 Likes
5
328

Re: String in EEPROM

Hi,

 

check the attached example.

Program Display manage the main view.

It shows a main value and all the active alarms, the alarm string to be shown must be written as constant inside the program (in this case you are not using RAM...) and you have to keep them aligned with what defined in Configuration for AL folder.

 

The reason for which it is not possible to access to the string defined in Configuration is that the code generated when you compile a project define them more or less in the same way I did in Display. 

Attachments
Tags (2)
otrotabi
Lieutenant
Lieutenant
0 Likes
3
300

Re: String in EEPROM

Thank you. This is exactly what I need.

 

I never used the never ending "while TRUE do" loop plus the timer before. I still have a sort of linear frameset to program and try to be careful not getting into an infinite loop that somehow hangs the PLC. Great solution!

 

This line :

 

BiosMenu:= (OverwriteLocalDisplay(0,'',0,1,0,1)=1);

 

is useless in this program.  What would you use BiosMenu for in a full blown project ? 

 

Tags (1)
FedericoM
Lieutenant Lieutenant
Lieutenant
0 Likes
2
296

Re: String in EEPROM

Usually I prefer to avoid the use of WHILE TRUE, but in this case the exit function is always verified with AlarmVisualization[0].

 

You are right, in this example:

BiosMenu:= (OverwriteLocalDisplay(0,'',0,1,0,1)=1);

is useless.

 

I use it in some other program in the display management.

Tags (1)
otrotabi
Lieutenant
Lieutenant
0 Likes
1
293

Re: String in EEPROM

I´ve had some issues in the past with alarms popping up in case they appear when I am doing something like cchanging a parameter. 

 

However this is not the case, alarms do not interfere when you are in the BiosMenu or a user defined menu. I must go back in time to a former project to find out what was really going on.

 

What kind of things would you do or not do if BiosMenu is true ?

Tags (1)
FedericoM
Lieutenant Lieutenant
Lieutenant
0 Likes
0
290

Re: String in EEPROM

SysKeyFunctions[] can be triggered also when you see Free on the display.

 

You might want to disable icons of the display (sysLocalLeds[]) when you are in the bios menu.

Tags (1)
otrotabi
Lieutenant
Lieutenant
0 Likes
0
113

Re: String in EEPROM

Hello @FedericoM 

 

Based on M171_DynamicView I made a couple of simple modifications and developed an alternative way to do the same thing without the alarm visualization array.  

 

I have uploaded it here: https://schneider-electric.box.com/s/8bwfjcdn95sd3e8xlsqkx5zii3hqa91q

 

Although the array does not seem to change much in a simple program, when you are trying to squeeze whatever you can from the TM171 it does make a small difference in terms of the AutoVars space error.

Tags (1)