GoranP Geschrieben February 22, 2017 at 19:00 Geschrieben February 22, 2017 at 19:00 Hello. I have a stack with a Step-Down, 2 Master Brick's, Ethernet, and some bricklets, (2 Industrial Dig In, 2 Industrial Dig Out), and a PTC module. I use Python for programming. Connection is OK, the normal function also. BUT i would like to use the IPConnection.CALLBACK_DISCONNECTED. I have made a callback function, for get a notice that i have lost the connection. When i test it, by remove the network cable from the stack, i don't get the callback. Any ideas what i could have wrong or missed? Or do i have missunderstand the functionality? // Göran Zitieren
GoranP Geschrieben March 3, 2017 at 19:10 Autor Geschrieben March 3, 2017 at 19:10 I'm new on Python programming, on the TinkerForge's modules and on API. But I would like to understand was is happening and when. To be able to understand why things are as they are, I have made a small test project with a StepDown module, a Master Brick and a Ethernet module. The code I have used, is basicly 'example_rugged.py' with code parts from example_authenticate.py, example_enumerate.py and from the API-doc online. See atteched code : gp_test_rugged.py I have tested in two ways, with USB-cable and with a ethernet connection. In both cases was the stack powered from a external battery pack. What I want to archive, is a way to handle condition that could occure, like - the program is started before the stack is ready, (powered up and connected), - disconnected network, (power loss to the switch), etc. - power down on the stack, - etc. The difference in the test code is the HOST address, in my code block I have 2 definitions for HOST, and I just moved the #. Testcase (A) - connected through USB (for output results, see Testresult-(A).txt) I got good responces, and was able to handle almost any case. Testcase (B) - connected through ethernet (for output results, see Testresult-(B).txt) The most funny thing here was 2 things: 1. When I disconnect the ethernet cable, OR the stack power, it took always about 25 seconds before I could notice it in the program. When I reconnect the ethernet or power, it where able to get connected again. Testcase (B_2) - connected through ethernet (for output results, see Testresult-(B)_2.txt) In this case was it so, that the stack was not ready, (no ethernet connection or stack power). Hear I got an error and program was stopped. My questions, for testcase (B) and (B_2) : A/ How should I do, so the program could handle startup with no initial connection to the stack? B/ How should I do, to reduce the time before the program notice that it has lost the connection to the stack? This testproject should be my template for the future project's. More of the upcoming project's will be done with just ethernet connections between stack's and computer(s). I look forward to your comments and advice's. // Göran Testresult-A.txtTestresult-B.txtTestresult-B_2.txt Zitieren
GoranP Geschrieben March 4, 2017 at 07:03 Autor Geschrieben March 4, 2017 at 07:03 Sorry, in some way the sorcerer file was not included. Here it is..gp_test_rugged.py Zitieren
photron Geschrieben March 6, 2017 at 14:30 Geschrieben March 6, 2017 at 14:30 Unfortunately the disconnected callback doesn't work as good as it could in case you disconnect the Ethernet cable or cut the power to the stack. We'll improve this soon by adding a heartbeat mechanism to the API bindings. Regarding test 2b: The connect() call of the IP Connection is blocking. It'll fail with an Exception if it cannot connect. You can catch the exception and retry the call. Maybe we could add a async version of the connect() call, that would not block. I'll at that to my list of things to investigate, but I can't promise anything yet. Zitieren
GoranP Geschrieben March 9, 2017 at 18:27 Autor Geschrieben March 9, 2017 at 18:27 OK, that sounds good. I like your modules and the API for them. But this was things that I found have "space for enhancement". Under the mean time I have found a solution on my problem in test 2b, startup with no ethernet connection or stack power. First I tried to to catch the exeption, but I didn't get success. So I solved it in another direction. Before I try to connect, I check if I have contact with the stack by sending repeating ping's. When I have contact, I start to open the ipconnection. I found a module, (ping.py), on the net. They say that this module has some limitations, you have to have administratives right in the system. For me has it solved my problem, for the moment. I renamed the module to ping_gp.py and added a new function in this module to give me an answer that was eay for me to use. In my file I added following code before opening the ipconnection. isConnected = False while isConnected == False: pingcheck = ping_gp.check_connection_by_ping(ExampleRugged.HOST) if pingcheck >= 0: print("The unit [%s] answer in %0.4f ms." % (ExampleRugged.HOST, pingcheck)) isConnected = True else: print("The unit [%s] didn't answer at all !! (AnswerCode %0.1f)..." % (ExampleRugged.HOST, pingcheck)) # Connect to brickd, will trigger cb_connected self.ipcon.connect(ExampleRugged.HOST, ExampleRugged.PORT) This is not the smartest or most beautiful solution, but it solved my problem. // Göranping_gp.py Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.