Shepard Test Stand

This chat log has to do with the challenge J put forth to redo Shepard's Processing app in Python in 10 days, and how the platform that's evolving might be turned into a platform to encompass many of Mach 30's data collection needs for the future.

Have you started the port yet Jeremy?
Chris - 12:32 PM

Yeah. I started on a loose MVC architecture and am working on the "model" now. It's not a true model, but it's close enough I think.
I've already got it auto-detecting the Rabbit, which was a little bit of a pain to get working reliably in Processing.
I'm also structuring the code so that it will be easy to switch to TCP for Shepard 2.0.
Jeremy - 12:57 PM

This week is shaping up to be busier than I expected though, so I'm not sure I'll have enough time to meet the challenge.
Jeremy - 1:04 PM

I was thinking that it might be handy to have the UI divorced from the M and C portions by a TCP connection. The controller would be the TCP server and the view would be the client. Anyone who connects to the controller from localhost would get the full-blow control interface, but anyone who connects from an external address would get a read-only interface. That way students could watch the test in real time if the teacher has the chops to set up the network.
Jeremy - 1:08 PM

Sounds good
Chris - 1:29 PM

Although, as I'm thinking about it, we could just simplify it to client/server and drop the controller.
Also, since we're now auto-detecting the Arduino, and if we're not going to handle ignition control in the software, there wouldn't have to be two interfaces.
Jeremy - 1:32 PM

That makes good sense, Jeremy.
Aaron - 1:54 PM

I could see value in having view-only capabilities, but I think for now it'd be best to leave that functionality out
Chris - 2:02 PM

With this architecture there's really nothing to control. Every client gets its own data, and that's what all the other controls are concerned with.
Jeremy - 2:07 PM

It also solves one problem I had with the web based interface which was how to get the data files to the clients.
Jeremy - 2:09 PM

Can this architecture work for things other than a ground station such as TVAC control etc?
Aaron - 2:20 PM

Hopefully I can have this server side done by tonight, but I don't know.
I think it could for the TVAC.
Jeremy - 2:21 PM

The reason I ask is that we need some sort of common command and control framework for future projects.
TVAC is just the tip of the iceberg...
Aaron - 2:22 PM

So we need to plan for view only to be future proof, right?
Jeremy - 2:23 PM

It should be extensible, and be able to do point to point, multipoint (broadcast) and multiple control in some circumstances.
Yep
Aaron - 2:24 PM

When would we use multicast?
Jeremy - 2:25 PM

Imagine a lab with all kinds of equipment, each with one of these controllers connected to a network. The operators in the lab would need the ability to monitor and control multiple systems, and in some cases two or more may need to control a device or pull data from it.
Aaron - 2:27 PM

So, I agree it would be good to have it engineered as such, but I also would keep in mind that its hard to engineer something for the future with only one slightly related point of reference
Chris - 2:28 PM

...or a flight deck
Aaron - 2:28 PM

We should worry about the current Shepard first and foremost, and worry about making everything extensible and modular for future projects later
Chris - 2:29 PM

Agreed Chris.
Jeremy - 2:29 PM

This is after all a proof of concept that we can replace a bunch of the Processing bit
Chris - 2:29 PM

So we would have the sensors broadcasting and have the UI aggregate them?
Jeremy - 2:30 PM

Agreed... but if we hit some decision points or low hanging fruit, we should steer those toward the future possibilities.
need to head out.
Aaron - 2:31 PM

Ok. I think that if we can get J Python Shepard software to QA we'll have some breathing room to hash out architecture. That would be the perfect time to tear down the proof of concept to talk about where to go next.
Jeremy - 2:33 PM

Mhmm
Chris - 2:33 PM

I'm a little disappointed that GTK doesn't have more mainstream support for data binding.
Jeremy - 2:51 PM

My understanding from other people is that Gtk is a bit archaic now a days as far as GUI API's go
Chris - 3:14 PM

Yeah, I could agree with that. Should we look at Qt?
Jeremy - 3:15 PM

I doubt it would be much better. Qt is older than Gtk+
Chris - 3:35 PM

But it's more actively maintained and used I think.
Jeremy - 3:37 PM

I can do some research in a little bit when I get home
Chris - 3:38 PM

Cool, thanks.
Jeremy - 3:40 PM

http://www.wikivs.com/wiki/GTK_vs_Qt
http://stackoverflow.com/questions/2810808/gtk-vs-qt-language-bindings
From those two, and some others, I'm starting to lean towards Qt
Chris - 4:14 PM

Yeah. I have a personal bias towards GTK because it's what I'm used to, but it might be time to put that bias aside.
"More used to" I should say.
I don't like KDE, which is based on Qt, which adds to my bias.
Jeremy - 4:15 PM

There's a charting library for Qt that you have to pay for, and there's also this: http://qwt.sourceforge.net/
Jeremy - 4:24 PM

I'm headed out for awhile. I may be back on this tonight, and I'm at least planning to get back to it in the morning.
Jeremy - 5:04 PM