NOTE: Opto22 G4 Logic is "reverse" IE 0=TRUE, 1=FALSE as seen at the GPIO
It is populated as follows:
Pos 0 GPIO pin 40 GPIO 21 DC Output
Pos 1 GPIO pin 37 GPIO 26 DC Output
Pos 2 GPIO pin 38 GPIO 20 DC Output
Pos 3 GPIO pin 35 GPIO 19 DC Input
Pos 4 GPIO pin 36 GPIO 16 DC Input
Pos 5 GPIO pin 33 GPIO 13 DC Input
Pos 6 GPIO pin 31 GPIO 6 DC Input
Pos 7 GPIO pin 32 GPIO 12 DC Input
In my GPIO settings in Codesys (3.5.13.0 Runtime) I have my IO configured (GPIO Parameters) as follows:
GPIO 21 Output (NOTE: on all of these I cannot declare a "default value")
GPIO 26 Output
GPIO 20 Output
GPIO 19 Input
GPIO 16 Input
GPIO 13 Input
GPIO 6 Input
GPIO 12 Input
GPIO OTHER "Input" to prevent them from being in an unknown state
Lastly these are all mapped as follows:
Output0 Bit 21 %QX2.5
Output1 Bit 26 %QX3.2
Output2 Bit 20 %QX2.4
Input3 Bit 19 %IX2.3
Input4 Bit 16 %IX2.0
Input5 Bit 13 %IX1.5
Input6 Bit 6 %IX0.6
Input7 Bit 12 %IX1.4
Note that my inputs all "work as advertised" (TRUE if 0, FALSE if 1)
One last detail is that in my main scan (Task Cyclic 20mS), I have a call to "initialize the Outputs to off (Logic TRUE).
This is done by declaring a variable "ScanOne : BOOL := TRUE;" Scan 1 when TRUE calls a function ("FirstScan() ) where "Output0-2" are all set TRUE. "FirstScan()" then returns FALSE which is used to set the "ScanOne" bit FALSE. Note that FirstScan() is the first call of the main program.
Now for the main issue. If I do a power down, the outputs come back up "on" regardless of what the state is showing online in the GPIO. If I go back in and change my "FirstScan()" to FALSE, Run it by triggering "ScanOne", then change FirstScan() to toggle TRUE my Outputs behave as the should the rest of the time. If I "Reboot" (as opposed to power down) they remain in the correct state and operation.
Note that I do not beleive this to necessarily be a function of Debian. I have "disabled the (Codesys) application" and powered down and back up and the outputs remain off. Only when I have the Codesys application loaded and running does this issue come up. Its like the FirstScan() function is having no effect on the GPIO the first time around.
Does ANYBODY have any idea what this could be? I DESPERATELY need to find a solution as the OPTO22 IO is the most robust I can find that will work on 12 volt DC. Thing is I CANNOT have an output come up in a "cooked state" like this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
not really sure if we could help (due the fact that we do not know this controller in detail), would recommend
to ask Opto22 for support.
Almost sure that they could help on this.
BR
Edwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for getting back with me. From what I have seen the only thing that needs to happen is for the output pins of the Pi to default to TRUE when the runtime loads. Ive looked at the GPIO .xml file. Do you have any documentation that describes the fields and their possible values in this file? I would like to duplicate one of the existing GPIO .xml's but have it start with the outputs being "TRUE" (off in Opto22 land). I have noticed that in the configuration for the GPIO there is a "default state" column but I cannot access it from the engineering software. This would be my preferred method but if I must I will create a .xml just for this configuration.
I am wondering if the key to this is in the following section of code in the GPIO DevDesc.xml:
Im assuming that "<value>2#000</value>" sets the GPIO pin for input (default state at boot) and <value>2#001</value> sets the pin in the controller as an output (defaulting "low"). Here again my ASSUMPTION is the 2#001 is what is being loaded to the controller at runtime when a pin is selected as an "Output". IF my assumption is correct then MAYBE there is a value that sets "Output" AND "TRUE" at runtime start. From what I see in the example Im going out on a limb to say <value> configures the pin as follows:</value>
This being said, Im not sure if some combination (ex. 2#011) would be "Output, default TRUE". Another possible option I could possibly see would be something along these lines. Instead of:
I also have an email in to Opto22 but Im afraid they will bounce it back as being on your (Codesys) side because they only come up with the runtime enabled or when it starts (with GPIO outputs being logic FALSE thereby turning my outputs ON). I have also played with /boot/config.txt to configure default IO state but it seems to be overridden when the Codesys runtime starts up (and I assume after reading the .xml).
If I can get this worked out, my IO will be ready for the big leagues as I have yet to see anything as bulletproof as the Opto22 G4 modules.
Cheers,
Todd
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Greetings,
I have a project going on and have been fighting the GPIO for 2 days now. I am using the Opto22 P1-40-P carrier board with the G4PB8H IO rack.
https://documents.opto22.com/2199_Raspberry_Pi_Carrier_Board_Data_Sheet.pdf
http://documents.opto22.com/0274_G4_Dig_I_O_Racks_Header_data_sheet.pdf
NOTE: Opto22 G4 Logic is "reverse" IE 0=TRUE, 1=FALSE as seen at the GPIO
It is populated as follows:
Pos 0 GPIO pin 40 GPIO 21 DC Output
Pos 1 GPIO pin 37 GPIO 26 DC Output
Pos 2 GPIO pin 38 GPIO 20 DC Output
Pos 3 GPIO pin 35 GPIO 19 DC Input
Pos 4 GPIO pin 36 GPIO 16 DC Input
Pos 5 GPIO pin 33 GPIO 13 DC Input
Pos 6 GPIO pin 31 GPIO 6 DC Input
Pos 7 GPIO pin 32 GPIO 12 DC Input
In my GPIO settings in Codesys (3.5.13.0 Runtime) I have my IO configured (GPIO Parameters) as follows:
GPIO 21 Output (NOTE: on all of these I cannot declare a "default value")
GPIO 26 Output
GPIO 20 Output
GPIO 19 Input
GPIO 16 Input
GPIO 13 Input
GPIO 6 Input
GPIO 12 Input
GPIO OTHER "Input" to prevent them from being in an unknown state
Lastly these are all mapped as follows:
Output0 Bit 21 %QX2.5
Output1 Bit 26 %QX3.2
Output2 Bit 20 %QX2.4
Input3 Bit 19 %IX2.3
Input4 Bit 16 %IX2.0
Input5 Bit 13 %IX1.5
Input6 Bit 6 %IX0.6
Input7 Bit 12 %IX1.4
Note that my inputs all "work as advertised" (TRUE if 0, FALSE if 1)
One last detail is that in my main scan (Task Cyclic 20mS), I have a call to "initialize the Outputs to off (Logic TRUE).
This is done by declaring a variable "ScanOne : BOOL := TRUE;" Scan 1 when TRUE calls a function ("FirstScan() ) where "Output0-2" are all set TRUE. "FirstScan()" then returns FALSE which is used to set the "ScanOne" bit FALSE. Note that FirstScan() is the first call of the main program.
Now for the main issue. If I do a power down, the outputs come back up "on" regardless of what the state is showing online in the GPIO. If I go back in and change my "FirstScan()" to FALSE, Run it by triggering "ScanOne", then change FirstScan() to toggle TRUE my Outputs behave as the should the rest of the time. If I "Reboot" (as opposed to power down) they remain in the correct state and operation.
Note that I do not beleive this to necessarily be a function of Debian. I have "disabled the (Codesys) application" and powered down and back up and the outputs remain off. Only when I have the Codesys application loaded and running does this issue come up. Its like the FirstScan() function is having no effect on the GPIO the first time around.
Does ANYBODY have any idea what this could be? I DESPERATELY need to find a solution as the OPTO22 IO is the most robust I can find that will work on 12 volt DC. Thing is I CANNOT have an output come up in a "cooked state" like this.
Dear Codesys people,
Is this an issue I can get a fix for if I buy a support ticket? I'm becoming more desperate by the day.
Hi,
not really sure if we could help (due the fact that we do not know this controller in detail), would recommend
to ask Opto22 for support.
Almost sure that they could help on this.
BR
Edwin
Edwin,
Thanks for getting back with me. From what I have seen the only thing that needs to happen is for the output pins of the Pi to default to TRUE when the runtime loads. Ive looked at the GPIO .xml file. Do you have any documentation that describes the fields and their possible values in this file? I would like to duplicate one of the existing GPIO .xml's but have it start with the outputs being "TRUE" (off in Opto22 land). I have noticed that in the configuration for the GPIO there is a "default state" column but I cannot access it from the engineering software. This would be my preferred method but if I must I will create a .xml just for this configuration.
I am wondering if the key to this is in the following section of code in the GPIO DevDesc.xml:
Im assuming that "<value>2#000</value>" sets the GPIO pin for input (default state at boot) and <value>2#001</value> sets the pin in the controller as an output (defaulting "low"). Here again my ASSUMPTION is the 2#001 is what is being loaded to the controller at runtime when a pin is selected as an "Output". IF my assumption is correct then MAYBE there is a value that sets "Output" AND "TRUE" at runtime start. From what I see in the example Im going out on a limb to say <value> configures the pin as follows:</value>
<value>2#000</value> == Input
<value>2#001</value> == Output
<value>2#010</value> == PWM
<value>2#100</value> == Clock
This being said, Im not sure if some combination (ex. 2#011) would be "Output, default TRUE". Another possible option I could possibly see would be something along these lines. Instead of:
we could have:
I also have an email in to Opto22 but Im afraid they will bounce it back as being on your (Codesys) side because they only come up with the runtime enabled or when it starts (with GPIO outputs being logic FALSE thereby turning my outputs ON). I have also played with /boot/config.txt to configure default IO state but it seems to be overridden when the Codesys runtime starts up (and I assume after reading the .xml).
If I can get this worked out, my IO will be ready for the big leagues as I have yet to see anything as bulletproof as the Opto22 G4 modules.
Cheers,
Todd