Home » Eclipse Projects » 4DIAC - Framework for Distributed Industrial Automation and Control » Problem with QX in Raspberry pi (the block QX and IX dont work )
|
| Re: Problem with QX in Raspberry pi [message #1727904 is a reply to message #1727670] |
Tue, 29 March 2016 07:53   |
 Jose Maria Jesus Cabral Lassalle
Messages: 199
Registered: February 2016 |
Senior Member |
|
|
Hi! I don't know until what extend have you tested, but I would do a complete check to the system.
1. Regarding the connections, it seems that everything is fine, but the mapping between pin numbers and GPIO seems not to be right. You marked:
- Pin number 13 -> GPIO 2 -> Button
- Pin number 3 -> GPIO 8 -> LED
The pin numbers seem to be right, but the GPIO don't. According to http://www.raspberrypi-spy.co.uk/2012/06/simple-guide-to-the-rpi-gpio-header-and-pins/
pin number 13 is GPIO 27 and pin number 3 is GPIO 2. You should check that first.
2. Once the GPIO numbers are correctly detected, check through ssh like you did (echoing to export, direction and value) to test the LED and Button (the button part you forgot to write in your post, but it would be the same, but reading the value file instead of writing to it). The value echoed to the export file should be the GPIO and not the header pin number, just to be clear.
3. If the button doesn't work, try using a 5 V output instead of 3.3 V. If the LED doesn't work, maybe you could try another pin that is not shared (in this case, pin number 3 is used also by I2C).
4. When both are working, you should test it using the QX and IX FB tester as you did in your last photo. Before testing, I would unexport both GPIO in the ssh, to be sure that the file can be opened by 4DIAC. Test both QX and IX with the GPIO number as parameter, QI set to TRUE and first sending an INIT event and then the REQ and changing the VALUE input in QX or reading the VALUE output in IX.
If this doesn't work, maybe there's a problem with your networking. Try disabling the firewall.
5. When it works, you should try the Flip-Flop example with the right parameters in QX and IX. If it doesn't work, at least is a problem of the Flip-Flop application and that would be easier to fix.
Try the steps and see until which one both LED and BUTTON work.
|
|
|
| Re: Problem with QX in Raspberry pi [message #1727996 is a reply to message #1727904] |
Wed, 30 March 2016 07:13 |
|
In addition to the comments pointed out by Jose I want to add that according to your screenshots the IX block has an issue which it reports with QO = FALSE. The status string, which is unfortunately german (we need to fix this), says it couldn't read. The question for me now is do you get an error message already on INIT or after the first REQ event?
|
|
|
| Re: Problem with QX in Raspberry pi [message #1728071 is a reply to message #1727996] |
Wed, 30 March 2016 18:15 |
investigacioncp15103 uva
Messages: 12
Registered: February 2016 |
Junior Member |
|
|
hi
thank you very much for the suggestions.
first of all , I totally disabled the firewall on my computer , as suggested by Jose Cabra.
answering Alois Zoitl , I'm using the signs of the post https://www.eclipse.org/forums/index.php?t=msg&th=1075043&goto=1726062&#msg_1726062 about on initializing block.
this post says:
"try first to set the QI = TRUE, PARAM = 3 and then click the INIT event.
If the STATUS = OK then you can set the OUT parameter and click the REQ event."
I follow the instructions and when I press the button init , it changes the status to False Not initializate(you can see it in the picture)
however, if I initialize it without changing anything ( Qi and Out in false , parameter wich gpio port) the status is ok, and then modify Qi to true and Out to true it is still in ok until pulse req , the status change to false and kant net scheiben.
to confirm that the problem is in my system, could anyone pass me a file with the minimum configuration ( e_cicle , e_swicht , Qx, ix) ( Existing system) for making it easier to work
thank
Attachment: init3.png
(Size: 7.03KB, Downloaded 809 times)-
Attachment: init2.png
(Size: 6.73KB, Downloaded 912 times)
|
|
|
| Re: Problem with QX in Raspberry pi [message #1728143 is a reply to message #1728071] |
Thu, 31 March 2016 11:07 |
Jose Maria Jesus Cabral Lassalle
Messages: 199
Registered: February 2016 |
Senior Member |
|
|
I tried the same scenario in a Raspberry Pi, and got partially the same problem as you did. When I tried to initialize the GPIO 2, I got the same problem the first click (STATUS= FALSE), but it worked the second click (STATUS = OK). I mean, after clicking INIT another time after failing, the status was OK. If I deinitialize, the status is OK, and then the first-click problem comes again.
What the initialization function does is the following (PARAMETER = 2):
1. Opens the "export" file and writes 2 to it
2. Opens the file gpio2/direction
3. Writes "out" to it.
If any of the two first opening or the last write fails, the intiallization fails. So I started debugging it, and the problem didn't appear at all when steping on each line of code of the initialization function. Then, I put a breakpoint to each fail case and ran it without stepping, and the problem appeared again when opening the direction file.
In this case, the problem seems to be because when exporting the GPIO, you don't have permission to write to the files for a short time, and after that you have.
See: http://raspberrypi.stackexchange.com/questions/23162/gpio-value-file-appears-with-wrong-permissions-momentarily
How to solve it:
1. Change the forte code to wait for short time before openning the direction file (not the best fast solution)
2. Run forte with sudo.
I tried the 1. solution, not changing the forte code, but using a bash file to export and open inmediately, and then with sleep in the middle of them and the problem was solved in the bash script (this solution worked only once actually)
The 2. solution (user$ sudo forte) doesn't show the problem at all, and at the first click of the INIT event, the STATUS = OK.
So, try running forte with sudo to see if the problem dissapear, and try INIT twice to see if the second time it works.
|
|
| | | |
| Re: Problem with QX in Raspberry pi [message #1728262 is a reply to message #1728255] |
Fri, 01 April 2016 12:51 |
Jose Maria Jesus Cabral Lassalle
Messages: 199
Registered: February 2016 |
Senior Member |
|
|
It's really weird actually. But it seems to be something in your Pi, because I could solve it with sudo.
What I would recommend is:
First, I try to let the GPIO2 in a default state:
$ echo 0 > /sys/class/gpio/gpio2/value
$ echo in > /sys/class/gpio/gpio2/direction
$ echo 2 > /sys/class/gpio/unexport
Then, execute these commands in a bash script (not manually) to see if you get an error on any line:
#!/bin/bash
echo 2 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio2/direction
echo 1 > /sys/class/gpio/gpio2/value
If no error ocurred, and before debuging, you could put the GPIO again in a default state, and then run the FBtester again, and then check what happened with the GPIO in the Pi.
If the /sys/class/gpio/gpio2 folder didn't appear, it means that opening the export file failed.
If it is there the folder, but /sys/class/gpio/gpio2/direction is "in", then opening or writing to /sys/class/gpio/gpio2/direction failed. (At least in my PI, when exporting, the direciton is the same as the last time)
|
|
|
Goto Forum:
Current Time: Thu Apr 25 06:05:10 GMT 2024
Powered by FUDForum. Page generated in 0.03252 seconds |
] 
Search
Help
Register
Login
Home
