Initializing functions is lacking for pigpiod

[KigenHasebe]

I encountered a problem which makes hard somewhat the use of S3OneGPIO. First, I write a wanted fix.

"Extensions/scratch3_onegpioRpi/index.js" should incorporate some adequate initializations for pigpiod.

The problematic situation is introduced by starting a Scratch script which has some S3OneGPIO block "Read Digital Pin" from a GPIO pin which is set accidentally output state. This is incidental. As a matter of course, the Scratch script does not work. I can change the pin state to input with WebIOPi.

The problem is that I can not effectively restart the script even after common recovering operations. Following operations do not work: restarting the Scratch script with red and green flags, reloading the script from the computer, rereading the OneGPIO Web page, restarting the browser (Firefox and Chrome)

S3OneGPIO gets stuck in a bad condition. In the bad condition, the script receives no input signal at all from the pin now in appropriate input state. To tell the fact, no changing external signals do not arrive at any application programs which read the now input GPIO pin. I can certify that graphically with applications such as WebIOPi and piscope. By the way, I have no electrical means to read out the value of the pin.

The means with which I apply to get out of the bad S3OneGPIO condition is running a Python program in the server Raspi. The simple program uses the pigpio library and works equivalently as the Scratch script except for the additional initializing operations. I paste the program at last of this post. I run the program on Thonny,

The Python program never suffers the bad condition on the similarly accidental output state pin. When I start the program, it automatically changes the state of the pin from accidental output to appropriate input and runs successfully, This is the fact even when the Scratch script stays in in the bad condition.

The important matter is that after the successful run of the Python program, I can easily restart the failing Scratch script with red and green buttons in success. No other bothering recovering operations are necessary. Nevertheless Python programming and operations as well as WebIOPi are hard for casual Scratch users.

I think the Python program adequately initialize pigpiod though the current "Extensions/scratch3_onegpioRpi/index.js" fails to do so. S3OneGPIO has no initializing blocks unlike the Scratch 3 Desktop built in Raspbian Buster, which has a block "set gpio X to input ...".

For the reference my environment on RasPi is:

Raspberry Pi 3 B+
Raspbian Buster Linux pi 5.4.51-v7+ #1333 SMP Mon Aug 10 16:45:19 BST 2020 armv7l GNU/Linux
Thonny 3.2.6-1+rpt1
Python 3.7.3
pigpio V71 (1.71-0~rpt1)
s3r &
rpi_gateway.py installed on 2020/10/22
S3OneGPIO downloaded on 2021/01/07

---

The Python program which does the equivalent thing as the Scratch script:

SW_PIN = 25
LED_PIN = 14

pi = pigpio.pi()

pi.set_mode( SW_PIN, pigpio.INPUT )
pi.set_pull_up_down( SW_PIN, pigpio.PUD_UP )
pi.set_mode( LED_PIN, pigpio.OUTPUT )

mode = 0

while True:
sw = pi.read( SW_PIN )
if ( sw == pigpio.LOW ):
if ( mode == 0 ):
pi.write( LED_PIN, pigpio.HIGH )
mode = 1
else:
pi.write( LED_PIN, pigpio.LOW )
mode = 0

    while ( pi.read( SW_PIN ) == pigpio.LOW ):
        time.sleep( 0.1 )

[MrYsLab]

Thanks for your question and the details you provided. The one thing I don't understand is how was the following statement from above is created:

The problematic situation is introduced by starting a Scratch script which has some S3OneGPIO block "Read Digital Pin" from a GPIO pin which is set accidentally output state.

If I go into Scratch and first do a read of an output pin connected to an LED and then write to that pin, all works as expected. If I first write to that pin and then to a read, I can still affect the pin through the write block.

Could you please explain what I need to do to get the system in the state that you describe?

Thanks.

[KigenHasebe]

Thanks for your always quick response very much.

I certified again the case carefully. Prior to that, I rebooted the Scratch server and the Browser (in Windows 10 on VirtualBox VM) and the pigpiod server (RasPi).

My conclusion is that the suspect which make S3OneGPIO stuck in a bad condition is S3OneGPIO itself.

My simple procedure to reproduce the incidents that are not accidents follows:

Load and run newly the Scratch script in S3OneGPIO page (http://local:8601).

At first, the state of the GPIO pin in the problem is input and high. This state is set at boot time by a code line "gpio=18=ip,pu" in "/boot/config.txt".

As I push and release a tact switch connected to the GPIO pin, the contact state (low or high) changes correctly in WebIOPi.

When I start the Scratch script, WebIOPi freezes the contact state shown to low. Thus the Scratch script does not work from the beginning.

I can melt the freezed condition when I run the yesterday Python Program. Once melted, the good condition continues and I can rerun the script any number of times successfully.
However, when I reload and run the Scratch script, this good condition breaks.

I suspect that when S3OneGPIO starts a fresh Scratch script, S3OneGPIO changes the state of input pins to output and low. Afterwards WebIOPi and I can never see the changing contact state any more because pigpio does not read from output pins. The reason that WebIOPi cannot see the input/output state is unknown. Furthermore S3OneGPIO blocks are not able to set the input/output state.

More importantly, S3OneGPIO does not change the state of input pin for not-fresh Scratch script.

Anyway I hope the initializing code of Python program helps.

By the way, how to upload my problematic Scratch script?

[KigenHasebe]

I am sorry very much.

I want to cancel the previous post and repost the corrected one. I failed to put together the observations.

--- corrected post

I certified again the case carefully. Prior to that, I rebooted the Scratch server and the Browser (in Windows 10 on VirtualBox VM) and the pigpiod server (RasPi).

My conclusion is that the suspect which make S3OneGPIO stuck in a bad condition is S3OneGPIO itself.

My simple procedure to reproduce the incidents that are not accidents follows:

In a fresh (newly read) S3OneGPIO page (http://local:8601), load and run the Scratch script .

Before I run the Scratch script, the state of the GPIO pin in the problem is input and high. This state is set by a code line "gpio=18=ip,pu" in "/boot/config.txt" at boot time.

As I push and release a tact switch which is connected to the GPIO pin, WebIOPi show the contact state (low or high) correctly.

When I run the Scratch script, WebIOPi freezes the contact state to low. My operation to push and release the tact switch does not arrive at the script. Thus the Scratch script which read the GPIO pin does not work.

I can run the yesterday Python Program to melt the freezed condition. Once melted, the good condition continues and I can reload and run the script any number of times successfully.
However, when I reread the S3OneGPIO page, this good condition breaks.

I suspect that when a fresh S3OneGPIO loads and starts the Scratch script, S3OneGPIO changes the state of input pins to output. Afterwards WebIOPi and I can not see the changing contact state any more because pigpiod does not read from output pins. The reason that WebIOPi cannot see the input/output state is unknown. Furthermore S3OneGPIO blocks are not able to set the input/output state.

More importantly, not-fresh S3OneGPIO does not change the state of the input pin when it runs the Scratch script.

Anyway I hope the initializing code of Python program helps.

By the way, how to upload my problematic Scratch script?

[MrYsLab]

I don't know why your config.txt has "gpio=18=ip,pu" in it. This is not set by my software. Below is the config.txt I have on my RPi. You have something in your enironment that set that value. The S3OneGPIO web page does not initialize the state of any pins and neither does s3-extend. The state on the RPi side is set when either a digital read or write block executes in the browser.
I do set the pull up resistor to a pull down state when a digital read block is executed.

Perhaps you can remove or comment out that statement in config.txt and see if things behave as normal, or better yet, reinstall a fresh version the Raspberry Pi OS.

config.txt

[KigenHasebe]

Thanks to you that my trouble is fixed. I apologize for my lack of understanding and confusion.

Following your advice, I added a pull up resistor to the tact switch and replaced "config.txt" file with the Buster original one. Now my trouble is resolved, I think.

Some explanation...

The tact switch is integrated into a ready-made control board which I utilize to build my self-driving toy car. Because adding a pull up resistor was tiresome, instead of that, I inserted the "gpio=18=ip,pu" line into "/boot/config.txt". By the way, "gpio=18" is another mistake and "gpio=25" is correct to be consistent with the Python program.

I did not think that pigpio happens to put back the setting at OS boot time to low (pulled down) state.

Very much thanks to your kind advice and explanation.

[MrYsLab]

I am glad that you were able to solve the problem. No need to apologize for your excellent questions.
The original intent of the RPi extension was to support boards such as the JamHat and PiBrella. Your robot pushed the RPi extension to its limits ;-).