NWT.Stuff

Is there a way to avoid the dependency of openPLC on WiringPi ?

I would like to map my IO using a Python routine on RPI start up and addressing GPIO as per the documentation on raspberry pi.org. 
https://www.raspberrypi.org/documentation/usage/gpio/

This would save me a lot of time if possible and reduce the risk of errors.

P.S. I don’t need the Monitoring Function in runtime if this uses the WiringPi mapping.

Many thanks in advance, Kevin 

 

 

 

Quote 0 0
thiagoralves
Wiringpi has nothing to do with monitoring or anything else on the webserver side. Wiringpi is the core library that provides GPIO access to the whole system. The OpenPLC Raspberry Pi driver is based on wiringpi. Without wiringpi OpenPLC simply won’t work with your GPIO pins.

Now, with that being said, I’m under the impression that what you’re trying to accomplish is something else. What exactly do you mean by “addressing GPIO” with a start script?
Quote 0 0
NWT.Stuff
Bizarrely enough my Issue is related to COVID-19.

I have two raspberry Pi's running Python Main Routines and a Flask Web Server for each.  I want to bring them together in 1 User Interface using PHP and OpenPLC.  I use different PIN mapping to the OpenPLC default.  Both Pi's are in a remote location that I cannot get to because of COVID-19.

My pre COVID solution would be to jump on a plane and happily rewire the Pi's to use the default pins used by OpenPLC.  Given the choice I would always prefer to the default settings in OpenPLC.

Unfortunately I cannot access the Pi's physically but I can access my remote LAN via a VPN connection.

I can show you how I would configure the IO normally (in Python) see below (I haven't used indexing to make the example clearer):-

# My RPI GPIO Configuration

import RPi.GPIO as GPIO

#Set GPIO Mode
GPIO.setmode(GPIO.BCM)

#Input Pin Variables
PinI0 = 7 # Physical PIN 26
PinI1 = 8 # Physical PIN 24
PinI2 = 9 # Physical PIN 21
PinI3 = 10 # Physical PIN 19

#Output Pin Variables
PinQ0 = 17 # Physical PIN 11
PinQ1 = 18 # Physical PIN 12
PinQ2 = 19 # Physical PIN 35
PinQ3 = 20 # Physical PIN 38

# Configure Inputs
GPIO.setup(PinI0, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.setup(PinI1, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.setup(PinI2, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)
GPIO.setup(PinI3, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)

# Configure Outputs
GPIO.setup(PinQ0, GPIO.OUT)
GPIO.setup(PinQ1, GPIO.OUT)
GPIO.setup(PinQ2, GPIO.OUT)
GPIO.setup(PinQ3, GPIO.OUT)

#Set Output Relays to HIGH
GPIO.output(PinQ0, GPIO.HIGH)
GPIO.output(PinQ1, GPIO.HIGH)
GPIO.output(PinQ2, GPIO.HIGH)
GPIO.output(PinQ3, GPIO.HIGH)


I am looking for the easiest way to achieve the same result using OoenPLC. Many thanks in advance, Kevin
  
Quote 0 0
thiagoralves
The easiest would be to edit raspberrypi.cpp and change the pinout at you will. You only need to do it once, no need to have any startup script to keep changing this. The picture below shows the relation between wiringpi numbering and Pi header: [gpio1]
Quote 0 0
NWT.Stuff
Hi Thiago,

My remap didn't work 
// DEFAULT #define MAX_INPUT 14
// DEFAULT #define MAX_OUTPUT 11
// WHAT I WOULD LIKE #define MAX_INPUT 8
// WHAT I WOULD LIKE #define MAX_OUTPUT 8
// TEST WITH 1 OUTPUT & INPUT
#define MAX_INPUT 1
#define MAX_OUTPUT 1
#define MAX_ANALOG_OUT 1

/********************I/O PINS CONFIGURATION*********************
* A good source for RaspberryPi I/O pins information is:
* http://pinout.xyz
*
* The buffers below works as an internal mask, so that the
* OpenPLC can access each pin sequentially
****************************************************************/
//inBufferPinMask: pin mask for each input, which
//means what pin is mapped to that OpenPLC input
// DEFAULT int inBufferPinMask[MAX_INPUT] = { 8, 9, 7, 0, 2, 3, 12, 13, 14, 21, 22, 23, 24, 25 };
// WHAT I WOULD LIKE int inBufferPinMask[MAX_INPUT] = { 11, 10, 13, 12, 14, 26, 23, 15 };
// TEST WITH 1 INPUT - WIRINGPI 11 - PHYSICAL PIN 26 - GPIO 7
[MAX_INPUT] = { 11 };

//outBufferPinMask: pin mask for each output, which
//means what pin is mapped to that OpenPLC output
// DEFAULT int outBufferPinMask[MAX_OUTPUT] = { 15, 16, 4, 5, 6, 10, 11, 26, 27, 28, 29 };
// WHAT I WOULD LIKE int outBufferPinMask[MAX_OUTPUT] = { 0, 1, 24, 28, 29, 3, 4, 5 };
// TEST WITH 1 OUTPUT - WIRINGPI 0 - PHYSICAL PIN 11 - GPIO 0
[MAX_OUTPUT] = { 0 };


I modified the cpp in the hardware layer folder. For each attempt I rebooted the pi, recompiled the PLC code and Ran the Program.

I started off with 8 out and 8 in then I stripped back to 1 in 1 out. 

I both cases the default mapping is still working e.g. QX0.1 PIN 8 & QX0.2 PIN 10 etc.

Am I missing a trick here ?

Kevin

    
Quote 0 0
thiagoralves
You didn’t do it right. This is C code, you need to keep the “int inBufferPinMask” in the line, as just [MAX_INPUT] makes no sense in C. Needs to be something like 
int inBufferPinMask[MAX_INPUT] = { 11 };

Also, as I said, for the changes to take effect, you don’t need to reboot the Pi neither upload a new program. What you need to do is go to the hardware tab, select the Raspberry Pi hardware layer again and click on save changes. This will reload the hardware layer modified by you into the system. If you don’t do this, you can reboot your Pi a million times, it will keep running on the original hardware layer 
Quote 0 0
NWT.Stuff
dohhhh!!!!  & thanks Thiago.  Will let you know how I get one 🙂
 
Quote 0 0
NWT.Stuff
Hi Thiago. successfully done. Just need to count how many pins I've fried now 🙂
Thanks for the help. much appreciated.
Quote 0 0
thiagoralves
NWT.Stuff wrote:
Just need to count how many pins I've fried now

Hopefully you still have enough pins to keep you project going! 🙂

I'm glad it is finally working
Quote 1 0
NWT.Stuff
Fortunately I'm working with virtual/prototype board test pins. The "real" ones are safely listening to python instructions for now 🙂

Looking forward to the switchover when I'm ready (progress report attached). The speed improvement is amazing thanks to OpenPLC & Modbus.

Have a good week. I know I'm in for an interesting one 🙂
Quote 0 0