String in EEPROM

[otrotabi]

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.

[FedericoM · Accepted solution]

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

[otrotabi]

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 !

[otrotabi]

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.

[FedericoM]

Hi,

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

[otrotabi]

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.

[FedericoM]

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. 

[otrotabi]

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 ? 

[FedericoM]

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.

[otrotabi]

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 ?

[FedericoM]

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.

[otrotabi]

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.