**** BEGIN LOGGING AT Wed Sep 26 03:00:00 2018 Sep 26 03:23:38 Has anyone ever used UART to make motors move via Flask app w/ a BBB? Sep 26 03:23:57 I tried. I failed. I think I have to use PWM signals for this specific board. Sep 26 03:26:09 The Sabertooth needs a 0.1uF cap and a 10K ohm resistor to make this reality an actual moving bot w/ PWM and sys_5v. Sep 26 03:26:15 BBB! Sep 26 03:29:24 I found some old caps. Yea! Sep 26 03:32:52 Making a low-pass filter! Sep 26 06:47:54 set_: analog mode isn't going to work since it needs 0-5V Sep 26 06:48:02 use one of the two serial modes instead Sep 26 06:48:10 I thought you already had that working a while back? Sep 26 06:50:27 mode 3 (simplified serial) seems particularly simple to use and it's probably best to start with that Sep 26 10:16:14 zmatt: Okay. I did get it to work but I wanted to try another way, i.e. w/ server too. Sep 26 10:16:24 I thought I would need PWM for that idea. Sep 26 10:16:31 ??? Sep 26 10:16:54 I know. My lack of experience comes into play again. Sorry. Sep 26 10:17:49 how does the hardware interface used have *anything* to do with whether your application runs as a server or not? Sep 26 10:18:22 I thought using UART may hinder my server. I obviously was wrong. Sep 26 10:18:43 no this isn't a lack of experience, how did you manage to jump to this conclusion? what made you think that you wouldn't be able to simply do things they way you already had working? Sep 26 10:18:58 Oh. Sep 26 10:19:51 I had the motors working w/ UART from the BBGW! I thought I could make a server w/ this set up, too. Sep 26 10:20:15 This is for the Sabertooth and not the MotorCape. Sep 26 10:21:14 okay, and then? Sep 26 10:21:30 At least, I did learn how to make a Filtered PWM. Sep 26 10:21:49 w/ Low Pass Filter! Sep 26 10:22:14 I'm waiting for an explanation of why you didn't use the code that was already working Sep 26 10:22:29 I am using it. Sep 26 10:23:01 You mean...I should use the software from pysabertooth to make the Sabertooth work w/ the server? Sep 26 10:23:03 05:23 < set_> I tried. I failed. Sep 26 10:24:34 I jumped to this conclusion b/c I could not get the server to work just yet. Sep 26 10:24:44 and... Sep 26 10:25:03 I was unaware of using UART for making servers work. Sep 26 10:25:12 and what error did you get that implied that pysabertooth was the problem? Sep 26 10:25:27 No response. Sep 26 10:25:50 The web page from my Flask application was unresponsive. Sep 26 10:26:07 It would not control the motors at all. Sep 26 10:26:13 and what error was logged? and how did it imply there was a problem with pysabertooth? Sep 26 10:26:23 Oh. Sep 26 10:26:31 so basically you're not debugging problems, you're just trying random shit Sep 26 10:26:40 I did not check the error logs. I received no errors. Sep 26 10:27:01 Oh. Random "shit" is my shtick! Sep 26 10:27:12 Oh. Sep 26 10:27:19 I did receive an error at some point. Sep 26 10:27:34 I mean, errors are printed to your server's output, so you should see them Sep 26 10:27:48 Trial and error works at times but this log info. sounds more promising. Sep 26 10:27:56 I know. Sep 26 10:27:56 Oh. Sep 26 10:28:00 I mean, you *are* testing the server by simply running it right? since I already told you countless times to test your program like that before trying to run it as a service Sep 26 10:28:16 Yes. I am testing it. Sep 26 10:28:45 and it didn't work yet printed no output? Sep 26 10:29:32 I think. Let my plug in again. Sep 26 10:29:57 Oh. Wait! My low pass filter is still plugged in. Sep 26 10:30:09 (needless to say, make sure your service, if you have one, is disabled until you're done testing your server) Sep 26 10:30:49 you'll obviously need to connect it properly again and set the dipswitches right Sep 26 10:30:55 Right! Sep 26 10:31:07 and check your original test (which used to work) still works Sep 26 10:31:13 Right... Sep 26 10:31:27 Then, I need to check the logs. Sep 26 10:32:02 if you simply run your program there are presumably no logs, it will simply print errors (but I'll admit this is an assumption, I'm not that familiar with Flask) Sep 26 10:32:30 zmatt: At one point, I did receive an error. Sep 26 10:32:53 But things worked at that point. Then, I went on to make the server. There were no errors w/ the server. Sep 26 10:33:45 I unplugged the low pass filter. I am plugged in now. Please hold. Sep 26 10:34:08 I will use pastebin for the error. Sep 26 10:34:19 and I will give the software so you can see. Sep 26 10:34:32 Just for reference. Sep 26 10:38:49 https://pastebin.com/gMRCuca4 is the software that runs w/ this error code: https://pastebin.com/ji6R3vgg. Sep 26 10:39:19 and noted, the server has no error codes and runs nicely but does nothing right now. Sep 26 10:40:41 this error happens when your little test program ends I presume? looks like a minor bug in pysabertooth, try omitting the saber.close() Sep 26 10:40:52 Okay. Sep 26 10:41:54 also show a pastebin of your server's output Sep 26 10:42:03 Okay. Sep 26 10:42:05 Please hold. Sep 26 10:42:28 Do you want the server software, too? Sep 26 10:42:36 sure I guess Sep 26 10:42:37 You were right. That worked. Sep 26 10:42:54 saber.close() was it... Sep 26 10:43:17 yeah looks like a bug in their cleanup handling is causing the port to be closed twice Sep 26 10:43:27 Oh. Sep 26 10:43:41 or rather, they're trying to send a command after it's already closed Sep 26 10:43:59 since it automatically does stop() and close() at the end of the program (when the Sabertooth object is destroyed) Sep 26 10:44:08 but stop() wants to send commands, which is impossible after close() Sep 26 10:44:15 Oh. Sep 26 10:44:15 so yeah, it's a bug Sep 26 10:44:20 a bug! Sep 26 10:44:24 but the simple workaround is not calling close() yourself Sep 26 10:44:32 done! Sep 26 10:44:54 obviously that's unrelated to whatever issue you're having with your server Sep 26 10:45:01 Right! Sep 26 10:45:56 Alright, the server is running and there are no issues. Sep 26 10:46:11 Please hold for the pastebin of this software. Sep 26 10:46:38 and the output of your server program Sep 26 10:46:49 A photo? Sep 26 10:47:05 what? no Sep 26 10:47:13 just use pastebin Sep 26 10:47:22 You typed output... Sep 26 10:47:38 How should I get output from what is working? Sep 26 10:47:50 the stuff your program prints to its output Sep 26 10:47:59 I got you. Sep 26 10:49:10 e.g. " * Running on http://yadayada" and whatever else it prints Sep 26 10:49:53 https://pastebin.com/tfx8tHrT is the software... Sep 26 10:50:05 Please hold for the print out of what is printed. Sep 26 10:50:52 I'm seeing a syntax error, lines 10 and 11 are indented Sep 26 10:51:11 so there's no way in hell it can be "running" Sep 26 10:51:19 and I wonder what made you think it is Sep 26 10:51:31 https://pastebin.com/DHvyLSQ9 Sep 26 10:51:50 I will check on lines 10 & 11. Sep 26 10:51:57 huh, it didn't complain about that? Sep 26 10:52:02 I know. Sep 26 10:53:19 I do not see the indentation. Sep 26 10:53:44 the if statement? Sep 26 10:53:48 oh wait never mind I'm a moron Sep 26 10:53:58 Do not call yourself such things. Sep 26 10:54:17 ohhhhh, those are decorators on def updates() Sep 26 10:54:42 jeez, don't put a newline between those decorators and the function they're decorating, that's confusing as hell Sep 26 10:55:03 Okay. Sep 26 10:56:00 it's also not good that it think it's in production mode instead of development mode, but I'm not sure how it decides that Sep 26 10:56:01 One thing I noticed from the way things are situated is this idea... Sep 26 10:56:15 Python3 vs. Python2. Sep 26 10:56:46 I can use Python3 in the future. They stop that idea on the print out before the server runs. Sep 26 10:56:51 why are you using python 2 ? Sep 26 10:56:57 B/c...I am lazy. Sep 26 10:57:04 don't use python 2 Sep 26 10:57:06 Fine. Sep 26 10:57:17 too lazy to write "python3" instead of "python" at the top? Sep 26 10:57:22 Right! Sep 26 10:57:31 Plus, I have to change some print statements. Sep 26 10:57:52 this("lalala") instead of this "lalala" Sep 26 10:57:52 also remove those time.sleep statements Sep 26 10:57:56 Okay. Sep 26 10:59:05 also do this in your shell before running your program to enable development mode: export FLASK_ENV=development Sep 26 10:59:21 Why should I do that? Sep 26 10:59:42 Oh. Sep 26 10:59:44 Okay. Sep 26 10:59:45 it changes the defaults to be suitable for development rather than production Sep 26 11:00:03 also flask actually warns you about it: WARNING: Do not use the development server in a production environment. Sep 26 11:00:41 Okay. Sep 26 11:00:44 Done! Sep 26 11:00:57 zmatt: Please hold. I will be right back. Sep 26 11:01:01 Is this okay? Sep 26 11:01:32 brb Sep 26 11:04:56 overall it's a bit weird it's not working though, it indeed doesn't seem to be giving any error Sep 26 11:06:31 I know... Sep 26 11:06:55 I thought it was a communication error but the system works as is w/out the server too. Sep 26 11:07:13 I will keep testing. Sep 26 11:07:37 It could have been those time.sleep() functions. Sep 26 11:07:51 no those just make your server pointlessly slow Sep 26 11:08:04 Oh. Sep 26 11:09:00 w/ the L298s on the MotorCape, they work like a charm. Sep 26 11:09:24 It could be on my side, too. Sep 26 11:09:33 I will check the DIP switch. Sep 26 11:09:50 I tried simple serial and packetized serial. Sep 26 11:10:04 I will keep trying. Thank you, anyway. Sep 26 11:10:09 if the dip switches were wrong, your standalone test program wouldn't work either Sep 26 11:10:16 Oh. Sep 26 11:10:33 and you confirmed that worked right? Sep 26 11:10:38 Right! Sep 26 11:10:53 It runs, stops, and then runs in the opposite direction. Sep 26 11:11:22 Now, w/out error codes from those saber.close() statements. Sep 26 11:13:16 I may need more than one address for my DIP switches. This is all i could configure so far. Sep 26 11:13:31 ? Sep 26 11:15:15 I use an address on my chip on the Sabertooth. Sep 26 11:15:33 It controls motors. Sep 26 11:16:00 I know, but why are you suddenly mentioning it? Sep 26 11:16:06 Oh. Sep 26 11:16:23 you have the sabertooth working with your test Sep 26 11:16:25 B/c, I thought that this may be something to do instead of using their library. Sep 26 11:17:43 I could program it w/ (decimal, binary, hex). Sep 26 11:18:09 I don't understand what you're saying Sep 26 11:18:28 you have working code to control the sabertooth Sep 26 11:18:39 the only question is what's going wrong in the environment created by Flask Sep 26 11:18:46 which I'll admit is a bit puzzling Sep 26 11:19:20 Oh. In the instructions on the Sabertooth 2 x 12, typing out software w/out the use of pysabertooth can be done w/ decimal, binary, hex format. Sep 26 11:19:33 That is all. Sep 26 11:19:43 I thought that I would bring this idea to your attention. Sep 26 11:19:58 But yes... Sep 26 11:20:10 I can go to pocoo on Freenode. Sep 26 11:20:18 I can ask them what may be going on. Sep 26 11:20:25 I have read the datasheet, I understand what it says, I just don't understand what it is you're trying to say about it Sep 26 11:20:33 Oh. Sep 26 11:20:57 it might indeed be useful to ask if Flask is creating an environment which might somehow interfere with the use of pyserial Sep 26 11:21:06 If I was to try their format instead of the pysabertooth library, I could at least try. Sep 26 11:21:07 Okay. Sep 26 11:21:19 I ask them that question. Sep 26 11:21:26 then you'd just be recreating pysabertooth, except probably buggier Sep 26 11:21:44 Okay. Sep 26 11:21:56 I will cease that idea. Sep 26 11:22:08 anyway, I'm afk Sep 26 11:22:20 Alright. Peace! Sep 26 11:22:24 See you later. Sep 26 12:21:29 #beagle is pretty much entirely monologues from set_ punctuated by zmatt occasionally expressing is frustration Sep 26 12:26:20 Thank you, ayjay_t. Sep 26 12:26:37 Where did everyone go? Sep 26 12:27:02 more periods and more quotation marks, please. Sep 26 13:00:11 m Sep 26 13:18:36 gm all Sep 26 13:19:03 anybody see the spam from basepusher@ or pierky15? Sep 26 13:19:27 just double-checking the spam filter settings. Sep 26 13:19:37 * jkridner wonders the latest on the dang logging issue. Sep 26 13:19:39 * jkridner sees nslu2-log Sep 26 13:20:28 jkridner: i do, and it fits into the general problems at the moment Sep 26 13:20:32 cool. http://logs.nslu2-linux.org/livelogs/beagle.txt looks up to date and free of spam! Sep 26 13:20:52 LetoThe2nd: you only see it due to being +o Sep 26 13:21:01 note it isn't in the logs. Sep 26 13:21:08 jkridner: yeah, i know Sep 26 13:21:21 we get rewarded with it to try to help out unauthenticated newbs. Sep 26 13:21:43 jkridner: alsready contacted staff for it, and they pointed that out to. hence i took no further action Sep 26 13:24:12 yeah I'm not seeing any spam Sep 26 19:25:22 zmatt: If you are around, the software for the motors from the Sabertooth that the BBGW controls now works. Sep 26 19:25:41 It was the UART1 issue I came across years ago. UART2 works fine! Sep 26 19:26:09 Just to refresh your memory. It is the Flask server and Python app. Sep 26 19:33:46 set_: what was the UART1 issue? Sep 26 19:34:06 set_: burned io pads? Sep 26 19:38:42 set_: ehm, but if it's a hardware issue, why did it only affect your server but not a standalone test? Sep 26 19:39:12 I have no clue. Sep 26 19:39:31 I think it is an older kernel and image. Sep 26 19:39:58 There might be some missing ______? Sep 26 19:40:05 I really do not know. Sep 26 19:40:10 Oh. Sep 26 19:40:11 no, you said you tested it earlier today Sep 26 19:40:11 I know! Sep 26 19:40:34 you confirmed the standalone test worked Sep 26 19:40:38 I know I did but I think the UART1 pins are used by the Motor Bridge Cape for some reason. Sep 26 19:40:40 Right! Sep 26 19:40:59 did you use a different uart in that standalone test? Sep 26 19:41:14 Okay, hold on. Sep 26 19:41:15 ... Sep 26 19:41:40 I used P9.24 and P9.26 for the standalone and the server and only the standalone worked. Sep 26 19:42:06 Then, I changed from those uart pins to P9.21 and P9.22 for uart function. Sep 26 19:42:26 Now, the server works and so does the standalone. Sep 26 19:42:28 just P9.24 (txd) I assume since the Sabertooth doesn't have any pin for reply data Sep 26 19:42:37 okay that just sounds like you somehow fucked up a test Sep 26 19:42:46 Probably! Sep 26 19:43:30 I have P9.21 to s1 and P9.22 to s2 right now! Sep 26 19:43:47 Everything works and w/ swiftness. Sep 26 19:45:00 Do you think it would work w/ just my Pin P9.21 to S1? Sep 26 19:45:14 Oh. Sep 26 19:45:16 I got you now. Sep 26 19:45:46 txd, transmission, is all I need. So, one pin does control both motors w/ the pysabertooth library. Sep 26 19:47:46 in packet serial mode, S2 is an active-low emergency stop input, according to the datasheet Sep 26 19:48:37 "Pulling the S2 input low will cause the driver to shut down." Sep 26 19:49:00 Aw! Even from a uart rxd pin, i.e. P9.22? Sep 26 19:49:18 connecting it to an uart rxd pin is complete nonsense Sep 26 19:49:23 Oh...the software is the reason it stops. Sep 26 19:49:26 you're tying two inputs together Sep 26 19:49:40 So, I should make an emergency stop button or something. Sep 26 19:49:53 you can leave it unconnected if you have no need for it Sep 26 19:49:58 Okay. Sep 26 19:49:59 Done! Sep 26 19:50:07 "It is pulled high internally, so if this feature isn't needed, it can be ignored." Sep 26 19:50:17 It is useless. You are correct. Sep 26 19:51:35 But...it would be cool to set up a button for "emergency" stops. Sep 26 19:52:07 I could call it a halt-bot. Sep 26 19:53:31 uart is more powerful than I once thought. Sep 26 19:53:43 could you pastebin the output of my show-pins utility for P9.26 after configuring it as uart 1 rxd as you did previously? I'm curious about something Sep 26 19:53:52 Sure. Sep 26 19:53:54 Please hold. Sep 26 19:55:15 Oh and when you typed out, I may have flopped on the testing, I just may hav done that. Sep 26 19:56:16 I typed that to type this: I may have put the S1 pin in w/ rxd by accident. Sep 26 19:56:55 * zmatt facepalms Sep 26 19:57:01 Hhahahahah! Sep 26 19:58:15 zmatt: Do you only want to see P9.26? Sep 26 19:58:51 if you accidently connected S1 to P9.26 instead of to P9.24 then that's explanation enough :P Sep 26 19:59:10 Hold on. They are low. Sep 26 19:59:13 Does that matter? Sep 26 19:59:16 ? Sep 26 19:59:27 okay paste the line for P9.26 Sep 26 19:59:31 Okay. Sep 26 19:59:59 P9.26 96 fast rx down 7 gpio 0.14 << lo P9_26 (pinmux_P9_26_default_pin) Sep 26 20:00:17 that's not configured to uart Sep 26 20:00:23 Sorry. Please hold. Sep 26 20:01:00 P9.26 96 fast rx up 0 uart 1 rxd ocp/P9_26_pinmux (pinmux_P9_26_uart_pin) Sep 26 20:01:24 yeah that's as it should be Sep 26 20:01:28 Hmm. Sep 26 20:01:35 so you probably did wire it wrong then Sep 26 20:01:46 So, I might have had P9.24 in S1. Sep 26 20:01:54 that would be correct Sep 26 20:01:58 Well, I was using two wires. So, that makes since. Sep 26 20:01:58 P9.26 would be wrong Sep 26 20:02:06 Oh. Then, it was P9.26. Sep 26 20:02:17 I only needed one wire. Sep 26 20:02:30 Using two was a mistake on my part. Sep 26 20:02:31 and S2 should be unconnected, though connecting it to P9.26 would not have been harmful, merely pointless Sep 26 20:03:07 Exactly. Pointless. I made the low pass filter and that is all she wrote. I was on some tangent of figuring things out. Sep 26 20:03:14 It was too easy and I beat myself. Sep 26 20:03:26 Sheesh. Sep 26 20:04:21 yeah that wouldn't quite have worked properly either since the Sabertooth wants 0-5V input in analog mode, so with a 3.3V output you would not have been able to go faster than 66% of max speed in forward direction Sep 26 20:05:00 Oh. Sep 26 20:06:35 I already mentioned that Sep 26 20:06:49 That is what confused me. I was thinking, "How could I set up something to make more communication efforts from the BBB to the Saber..." Sep 26 20:06:54 ? Sep 26 20:07:06 ??? Sep 26 20:07:19 But...I know now that I would have to be specific on voltage. Sep 26 20:07:24 as usual you lost me again Sep 26 20:07:33 zmatt: Do not go! Sep 26 20:07:47 the voltage issue only exists in analog mode, which you shouldn't be using anyway Sep 26 20:07:51 Fine. Sep 26 20:08:04 The software works and things are kosher for now. I will leave it alone for a bit. Sep 26 20:08:05 packet serial mode is the way to go, and you have it working now Sep 26 20:08:09 Right! Sep 26 20:08:36 I wanted to try it out w/ some C++ software. I found a book on the Atmel AVR chips. Sep 26 20:08:48 I thought, if and when, I might as well. Sep 26 20:09:27 ? Sep 26 20:09:43 zmatt: Would you if you could? Sep 26 20:09:47 Just kidding. Sep 26 20:09:51 ??? Sep 26 20:09:57 hahah. I am sorry. Sep 26 20:10:12 I am tearing up over here over the UART issue and how I botched it. Sep 26 20:10:47 in the future, double-check your connections when you have issues :P Sep 26 20:10:53 Yes sir. Sep 26 20:11:26 For what it is worth, I keep learning. This is good for me. **** ENDING LOGGING AT Thu Sep 27 02:59:59 2018