Initializing functions is lacking for pigpiod about s3onegpio HOT 6 CLOSED

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.

from s3onegpio.

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?

from s3onegpio.

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?

from s3onegpio.

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

from s3onegpio.

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.

from s3onegpio.

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 ;-).

from s3onegpio.