Open PLC and Industrial Automation card

[alexburcea]

Strange, my pi zero is still working.
The code for all our cards are located in OpenPLC_v3/webserver/core/hardware_layers/sequent.cpp, any opinion is welcomed.
I was commented out the line 970 to 973 to force update the LED's on each interval.

 

[dstorey]

I had a look through the code and i'm a little puzzled as to how it's running. Normally, you need to complete the functions initializeHardware(), finalizeHardare(), updateBuffersIn(), updateBuffersOut(). but there's nothing like this in sequent.cpp. What am I missing?

 

[alexburcea]

I was guessing you wish to look at the low level part of the code.
The one you talking about is in the /home/pi/OpenPLC_v3/webserver/core/lib/sm_cards.h

 

[dstorey]

ah, yes. that will take a bit of understanding.

 

[alexburcea]

Hi,

My program on raspberry pi zero is working for more then 24h.
Can you try on your raspberry with 100mS gap, just for testing purposes.

Thanks,
Alex.

 

[dstorey]

lasted 40 minutes before locking up.

 

[dstorey]

I changed Pi 3's too... see the same result.

 

[alexburcea]

My zero is still working. It will be hard for me to debug this without seeing the errors.
Can you see something in the web interface log when this is happening?

 

[alexburcea]

Hi, can you revert back the I2C to 100kHz and use 100mS gap?

 

[dstorey]

I will re-install with a brand new OS and default kernel and see what happens. I also have a Pi 400 that I can see if it will plug into that. I can't see what difference the pi would make ... there's def. something in the I2c communication causing a problem OpenPLC runs all day when I use GPIO and not the Sequent HAT selection.

 

[alexburcea]

Definitely is the I2C or my drivers for the card or the card itself. I can not reproduce the locking, I decrease the interval and I see how sometime run slower and sometime faster because the Linux is not real-time OS and sometime have something else to do except for the I2C communications.
I will keep experimenting but until then can you give a command to the card while is locking? (somthing like "megaind 0 ledwr 1 0")

 

[dstorey]

unfortunately when it's locked it is completely unesponsive. That's why it's time to try again with a different kernel. I'm using a real-time preempt kernel at the moment and it's time to eliminate this.

 

[dstorey]

one thing ... I'm using a 32 bit kernel not a 64 bit one. is that an issue?

 

[alexburcea]

I do not see why this be an issue. I use a 64bits.

 

[dstorey]

Ok Alex, good news! Going back to default kernel fixed the crashing problem. Your routine ran all night. My original routine also runs but I still get that LED missing cycles - I'm wondering if it's an interaction of the task speed (100mS) and the switching time (500mS) of the TON/TOF calls. I was looking for a way in OpenPLC to call the sequent module every time the variable changed rather than every scan cycle, which is what I presume it's doing now. You said you had a different explanation for the led missing?

 

[alexburcea]

Hi,
This happens because from time to time the I2C transaction is wrong and my code does not update the leds if the new state is not different rom the old one.
Please comment out the lines 970 to 973 in OpenPLC_v3/webserver/core/hardware_layers/sequent.cpp.
You can also go with 50mS gap. Actually you can try with anything greater than 20mS.

 

[dstorey]

yep, that works really well. thx.

 

[dstorey]

One issue I found ... I can't use the GPIO lines if I've set OpenPLC to "Sequent HAT" in the hardware settings. I thought I should be able to use GPIO 23 which should not be used by the card. That is mapped to %QX0.2. It only works if I set the hardware settings to "Raspberry Pi".

 

[alexburcea]

Hi,
The driver does not expose the gpio pins of the raspberry. The pin you mention is not used by the card. Thiago advise not to mix the rpi driver with mine but thos can be done.