Hey all, I’ve just updated the Work In Progress utility for configuring the TinyG inside of ChiliPeppr. Currently you can view this by selecting “Configure” from the drop-down menu at the right of the TinyG widget. I believe John will move this to a dedicated button shortly.
As of right now the widget is display only, and will show you the values for the 4 motors and 4 axis in your connected TinyG. Updates are next!
Awesome. Can’t wait for updates.
Got home late tonight, Hooked up CopyTo (now a button) to an event that gets called. Trying to figure out the best way to genericise it like I did with the data population. Unfortunately, have a pressing customer issue at work. I just might be heading out West next week…
Newly update v0.3 introduces the CopyTo functionality. Configure one axis or motor, copy to one or more others to save time! Of course since this is still read only the term ‘configure’ is a bit of an exaggeration.
With hope, the connection issues others have are a thing of the past!
I just tried v0.3 from Linux-Chrome. Motor and Axis data correctly populating on open of Configure and on close-then-reopen-Configure sequence. Much Progress!
Kevin, just tried your stuff out and it looks great. I see all data coming back from TinyG. So, I think you’re good to go. No problems.
Thanks all …
Of course that version is NOT the latest. I may go back to what I did in that version, but I have since then tried to deal with the problems you (John) listed previously:
I’m seeing that a subscription occurs to “/ws/onconnect” like 8 times. That means you’ll get called back 8 times, which I’m sure you don’t want.
You should unsubscribe from “/recvline” when the dialog closes because when the user hits play, your method will get called 4 times for each line of Gcode which will slow the browser down.
Towards that end I’ve moved the subscribe and (previously missing) unsubscribe to surround the requests for information, and I’ve tried without success to get the TinyG to respond reliably in this configuration with or without the onconnect. As I mentioned last night it appears to get worse with time, and I suspected that had something to do with not unsubscribing, but by then I could get any data to go to or from the TinyG and it was bed time.
5 minutes (or so) after I post this I will email the current code to you.
Ok. Looked at your code. 1) I would subscribe to all events on show but only unsubscribe on hide. Right now you seem to unsubscribe based on a timer and I see nowhere where you subscribe again if user pulls back up the dialog. 2) the logic in your test method doesn’t seem to follow the flow of main workspace. You init your widget first and then the serial port widget. In the main workspace your widget will get initted way later upon user interaction. If you mimicked this in your test method you would not need to watch on connect.
Hide never gets called in the standalone mode, nor will it get called if the user closes the window by clicking outside its boundary, correct?
I’ll see what I can do about changing the order of initialization, thanks!
You can attach to a bootstrap modal dialog event called “hidden” via jQuery. When that event hits you should unsubscribe.