We've built a simple controller circuit for operating a 12v mechanical valve and some Scratch code to control it. We are running this system using a Pi3. We use GPIO (not physical pins) 4 and 24 to control the motor and GPIO 17 and 18 (Pins 11 and 12) to detect if the valve is open or shut.

When using ScratchGPIO8Plus our system works fine and we can shut off the valve's motor based on the values in GPIO 17/18, however when using Scratch2 (installed via the package manager) GPIO17 and GPIO18 always read low, regardless of anything we do.

The strangest part is if I open ScratchGPIO8Plus and Broadcast:


Then the code in Scratch2 will work as intended until I power cycle the system. I can close ScrachGPIO8Plus and Scratch2 and reopen Scratch2, I can restart the X server, no problem, the pins will be reading correctly. Only once I power the Pi down am I back to the state where Scratch2 Can't read inputs from those GPIOs.

Some more information

I use the same broadcast pattern as shown above on different GPIOs in Scratch2 and ScratchGPIO8Plus for sensing light and moisture with no issues (ie. I don't need to go into ScratchGPIO8Plus to make things work)

I can see that when I open ScratchGPIO8Plus and run the project a few processes start and don't stop when I shut the program down. However, manually stopping them does not affect how Scratch2 works. Starting them manually before I run Scratch2 has no effect (still broken). the processes are:


But I feel like this is a red herring.

I've monitored the value files in /sys/class/gpio/gpio[17/18] and there is no difference in the behavior there regardless of which version of Scratch I use. That is, the broadcasts in Scratch2 seem to be setting these files correctly.

I can see that a bunch of modules get loaded when I open ScratchGPIOPlus8 but they seem to have no effect on their own. I need to do the broadcasts in ScratchGPIO8Plus before Scratch2 will run the project properly.

What I'm actually asking

It seems that ScratchGPIO8Plus broadcasts are setting something low level that Scratch2 can then take advantage of, but at least for these two GPIOs, Scratch2 is not able to set that thing itself.

I have reasonably good Linux skills and what I'd like to know is where to look next. Does anyone have any suggestions as to what things could be being set by running the broadcasts from one version of Scratch and not the other? My hope is to find this thing, raise a bug report with the appropriate people and then just set it off at boot using a BASH script for now.

Before anyone suggests to just use different pins, I'd like to respectfully add that the controller is on a custom PCB (that I did not make) so it's not so straight forward. It can be remade but it involves modifying the board and sending off to China. Even so, I've spent 2 days on this now so I'd also just like to understand what's happening here. Unfortunately I don't have a copy of the circuit diagram handy now to share, although if you think it is needed I can find and attach one.

Many thanks.

  • If you think there is a fault it would be useful if you could provide a minimal scratch test script (or the equivalent in scratch) which exhibits the fault. If this is the official scratch from raspberrypi.org I suggest you post the question in that forum (there may be a scratch sub forum). The chap who does scratch will more likely see the question on that site.
    – joan
    Oct 29 '17 at 9:12
  • Thanks for getting back. I think in the end it will be a fault in Scratch so I might poke around there. I was just interested to know if any people with deep knowledge of the Pi / Raspbian could take a stab at what the issue would be.
    – minillinim
    Nov 1 '17 at 6:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.