Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » 4DIAC - Framework for Distributed Industrial Automation and Control » Problem with QX in Raspberry pi (the block QX and IX dont work )
Problem with QX in Raspberry pi [message #1727670] Thu, 24 March 2016 22:58 Go to next message
investigacioncp15103 uva is currently offline investigacioncp15103 uvaFriend
Messages: 12
Registered: February 2016
Junior Member
I've trying use block QX and IQ on my Raspberry pi and on my Raspberry pi 2 but it didnĀ“t run.
The compilation of forte was made including the module sysfs.
We already know that the hardware runs properly due to we checked it wit the following instructions:
Led:
echo 8 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio8/direction
echo 0 > /sys/class/gpio/gpio8/value
echo 1 > /sys/class/gpio/gpio8/value
button:
You can check these photos:

the correct voltages are 3.3 V and 0 v.
index.php/fa/25413/0/
index.php/fa/25413/0/
index.php/fa/25417/0/
otherwise the program works perfectly in forte-ide, several tests were performed:
virtualization module as seen in the following post:

https://www.eclipse.org/forums/index.php?t=msg&th=1075043&goto=1726046&#msg_1726046

a test was also conducted with the flip-flop and not working properly either, as you can see:

index.php/fa/25416/0/
index.php/fa/25415/0/

You can also check the ./forte command is launched with root privileges with the sudo command.
Also perform the render sequence discussed in this post
does anyone know what may be the mistake?I do not know what else can I try.
Re: Problem with QX in Raspberry pi [message #1727904 is a reply to message #1727670] Tue, 29 March 2016 07:53 Go to previous messageGo to next message
Jose Maria Jesus Cabral Lassalle is currently offline Jose Maria Jesus Cabral LassalleFriend
Messages: 76
Registered: February 2016
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 Go to previous messageGo to next message
Alois Zoitl is currently offline Alois ZoitlFriend
Messages: 523
Registered: January 2014
Senior Member
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 Go to previous messageGo to next message
investigacioncp15103 uva is currently offline investigacioncp15103 uvaFriend
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)
index.php/fa/25480/0/

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.
index.php/fa/25481/0/


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 427 times)
  • Attachment: init2.png
    (Size: 6.73KB, Downloaded 486 times)
Re: Problem with QX in Raspberry pi [message #1728143 is a reply to message #1728071] Thu, 31 March 2016 11:07 Go to previous messageGo to next message
Jose Maria Jesus Cabral Lassalle is currently offline Jose Maria Jesus Cabral LassalleFriend
Messages: 76
Registered: February 2016
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 #1728243 is a reply to message #1727670] Fri, 01 April 2016 10:01 Go to previous messageGo to next message
investigacioncp15103 uva is currently offline investigacioncp15103 uvaFriend
Messages: 12
Registered: February 2016
Junior Member
I try to "sudo" and does not work, add a youtube video to see if it helps.

https://www.youtube.com/watch?v=0PkV7gz4HbE&feature=youtu.be
Re: Problem with QX in Raspberry pi [message #1728251 is a reply to message #1728243] Fri, 01 April 2016 10:11 Go to previous messageGo to next message
Jose Maria Jesus Cabral Lassalle is currently offline Jose Maria Jesus Cabral LassalleFriend
Messages: 76
Registered: February 2016
Member
Good idea the video! But you are sending the INIT event with QI = FALSE, and that won't initialize it, but actually will de-initialize it, and therefore the REQ won't be able to read anything because QX is not initialize.

You should follow the sequence as the message post you linked before:

"try first to set the QI = TRUE, PARAM = 2 and then click the INIT event.
If the STATUS = OK then you can set the OUT parameter and click the REQ event."

TIP: Keep QI always TRUE, both for INIT and REQ.
Re: Problem with QX in Raspberry pi [message #1728255 is a reply to message #1728251] Fri, 01 April 2016 11:09 Go to previous messageGo to next message
investigacioncp15103 uva is currently offline investigacioncp15103 uvaFriend
Messages: 12
Registered: February 2016
Junior Member
hi:
I think you liked the video , I sent another link with the method you told me you which does not work

https://www.youtube.com/watch?v=nAm7iYPQhjU&feature=youtu.be
Re: Problem with QX in Raspberry pi [message #1728262 is a reply to message #1728255] Fri, 01 April 2016 12:51 Go to previous message
Jose Maria Jesus Cabral Lassalle is currently offline Jose Maria Jesus Cabral LassalleFriend
Messages: 76
Registered: February 2016
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)


Previous Topic:Structured text
Next Topic:Problem with translation from structured text to cpp
Goto Forum:
  


Current Time: Mon May 21 05:36:54 GMT 2018

Powered by FUDForum. Page generated in 0.02640 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top