07-27-2021 08:03 AM
I tried turning the LEDs off which were ON to initialize them using the following lines:
SetCtrlAttribute (sPanels.P_Hauptmenue, P_MAIN_LED_GET_UID,ATTR_CTRL_VAL,FALSE);
SetCtrlAttribute (sPanels.P_Hauptmenue, P_MAIN_LED_LOGIN,ATTR_CTRL_VAL,FALSE);
SetCtrlAttribute (sPanels.P_Hauptmenue, P_MAIN_LED_WRITE_DATA,ATTR_CTRL_VAL,FALSE);
SetCtrlAttribute (sPanels.P_Hauptmenue, P_MAIN_LED_READ_DATA,ATTR_CTRL_VAL,FALSE);
SetCtrlAttribute (sPanels.P_Hauptmenue, P_MAIN_LED_PRO_PAGE_DATA,ATTR_CTRL_VAL,FALSE);
SetCtrlAttribute (sPanels.P_Hauptmenue,P_MAIN_LED_NEW_PW_INPUT,ATTR_CTRL_VAL,FALSE);
But they stay on afterwards. am I doing something wrong?
Thanks a lot in advance.
Solved! Go to Solution.
07-28-2021 02:45 AM
I can think of two reasons:
- the code is not calling ProcessSystemEvents() or is not running "inside" RunUserInterface()
- On and Off color of the LEDs are the same
For the first: try adding ProcessDrawEvents() after the last SetCtrlAttribute() because using ATTR_CTRL_VAL defers the screen updates.
07-28-2021 03:04 AM
The function ProcessSystemEvents() exists already after trying to turn them off. They all had the green light through the function:
SetCtrlAttribute (sPanels.P_Hauptmenue, iAttribut, ATTR_OFF_COLOR, VAL_GREEN);
07-28-2021 05:47 PM
There may be tons of reasons for this malfunction:
The fact is that if you don't show all the relevant code we cannot do but guess: post a working code abstract so that we can understand what's going on.
08-03-2021 03:27 PM - edited 08-03-2021 03:30 PM
There is a function that I am using that turns the LEDs either in Yellow(while waiting to start). Green if passed and red if failed:
What I was previously doing if I want to do a new test is changing the LED colors to black, as they seem off. But then the LOGIN LED stays on for some reason.
ProcessSystemEvents(); is also used here to apply the functions to the LEDS..
Thanks a lot for the big help 🙂
void REPR_PANEL_TEST(int itest, int iStatus)
{
int iAttribut = 0;
switch (itest)
{
case initialize_test: break;
case CHIP: iAttribut = P_MAIN_LED_CHIP_IDEN; break;
case UserID: iAttribut = P_MAIN_LED_GET_UserID; break;
case DEF_LOGIN: iAttribut = P_MAIN_LED_LOGIN; break;
case WRITE_EE: iAttribut = P_MAIN_LED_WRITE_DATA; break;
case READ_EE: iAttribut = P_MAIN_LED_READ_DATA; break;
case PROTECT_ACT: iAttribut = P_MAIN_LED_PRO_PAGE_DATA; break;
case PW_GENERATE: iAttribut = P_MAIN_LED_NEW_PW_INPUT; break;
}
if(iStatus == RUN)
{
SetCtrlAttribute (sPanels.P_Hauptmenue, iAttribut, ATTR_OFF_COLOR,VAL_YELLOW);
}
else if (iStatus == PASS)
{
SetCtrlAttribute (sPanels.P_Hauptmenue, iAttribut, ATTR_OFF_COLOR, VAL_GREEN);
}
else if (iStatus == FAIL)
{
SetCtrlAttribute (sPanels.P_Hauptmenue, iAttribut, ATTR_OFF_COLOR, VAL_RED);
}
else if (iStatus == NEW_TEST)
{
// initializing all the filled elements
}
else
{
SetCtrlAttribute (sPanels.P_Hauptmenue, iAttribut, ATTR_OFF_COLOR, VAL_RED);
}
ProcessSystemEvents();
}
08-03-2021 04:23 PM - edited 08-03-2021 04:23 PM
Well, from this code I cannot understand what's happening; you need to be sure that all needed combinations of iTest and iStatus are executed in the code, so that the login led color is effectively changed: place a conditional breakpoint in the function that fires on the correct combination of both parameters, so that you are sure the function is executed with the correct combination.
Hypothetically, you could also be turning the LED on somewhere else in the code, so that changing the off color is irrelevant: you should check this case also.
BTW, ProcessSystemEvents () at the end of the function could be irrelevant if the calling already processes events or if it ultimately returns control to RunUserInterface ().
08-04-2021 01:17 AM
You were right. There was a line in the main Code after checking the login that gives the LED the "true" or "1" color. which is green.
So when I try to change the color and not the value of the LED. It does work but green stays on because the LED still has the value.
Thanks a lot for the help.