Project

General

Profile

Actions

Bug #4763

open

create gui to access datalogger program

Added by Daniel Crawl over 14 years ago. Updated about 12 years ago.

Status:
New
Priority:
Normal
Category:
sensor-view
Target version:
Start date:
02/05/2010
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
4763

Description

Provide an interface within engineering view to download, view, upload, and install the program running on the datalogger. Note: this may not be possible when using the SPAN software.


Related issues

Blocks Kepler - Bug #5321: sensor settings made by kepler user lost on SPAN restartResolvedDaniel Crawl02/23/2011

Actions
Actions #1

Updated by Derik Barseghian about 14 years ago

Have we decided changes like adding and removing a sensor, things that require changing the program itself, are something we the user to be able to do through kepler? Maybe not for the initial release of sensor view?

Actions #2

Updated by Derik Barseghian over 13 years ago

After discussion with Dan changing to an ER.
It would be nice to be able to see the entire program on the logger, and upload a modified version that you've likely prepared using the e.g. campbell's editor, but this would mainly be added functionality not commonly used and for expert users.

Actions #3

Updated by Derik Barseghian over 13 years ago

changing bugs from REAP to Kepler product

Actions #4

Updated by Derik Barseghian over 13 years ago

I've been playing with sensor-view and thinking through various usecases, and I think at least being able to see/read the program that's actually running on the logger would be of enormous benefit, e.g. from a site layout archival point of view. It's invaluable when looking at past measurements to be able to look at exactly what program was running on the logger at that time. When monitoring, it's also valuable for measurement context.
It's unclear if this is currently possible through SPAN, we may consider looking into it and trying to add this feature.
Also if we're able to view the program, ideally an advanced user could also edit it (uploading the new version to the logger).

Actions #5

Updated by Derik Barseghian over 13 years ago

Adding dependency - the solution to bug#5321 will likely add capability to get the program from logger, and then this bug just becomes making a gui display for this program which could be an attribute to the logger actor.

Actions #6

Updated by Derik Barseghian about 13 years ago

r55 adds a GetFileFromLogger method and associated get-file-from-logger command. E.g.

telnet gpp.msi.ucsb.edu 55055
get-file-from-logger CR800 CPU:conf.CR8

I've used the method to fetch ("upload from the logger") and write to gumstix disk the .TDF, .DIR, and CPU:conf.CR8 files. I've also tested the command on the cmd port. It only gives sensible results for all ascii files, like the CR8.

However there's currently a big caveat - one can currently only make 1 set of calls to cmdFileUpload. A 2nd set of calls gives an error. Since GetFileFromLogger uses cmdFileUpload, and since one of the first things cr1k_d does on startup is to use cmdFileUpload to fetch the .TDF, you won't be able to use this command until we fix this bug (or you temporarily comment out the initial .TDF fetch).

Actions #7

Updated by Derik Barseghian about 13 years ago

After a long fruitless struggle trying to determine why upload transactions from SPAN for the CR800 always returned the Invalid file name response (0x0d) on upload attempts after the first file upload, I took the plunge and updated my logger's OS from CR800.Std.09 to CR800.Std.22. I was aware of upload-related fixes in their revision history (http://www.campbellsci.com/70_121), but wasn't very confident they were relevant, and have been putting off the update until SPAN was more stable. Well, the update seems to have mostly done the trick! Instead of uploads never working after the first, they now usually work. I'll keep trying to track down why they occasionally fail as I start working on the kepler gui to show the program. Hopefully worst case scenario is Kepler will just have to retry a few times.

So far I haven't seen any problems related to the OS update - monitoring, changing sensor sampling rates, and spanTodt still work. But as I don't see the older OSes being offered as downloads, it may be good for Dan to stay on the older OS for awhile until I've tested this more extensively.

Actions #8

Updated by Derik Barseghian about 13 years ago

At r27575, on Site Import and site layout execution, the span-default active program is fetched from the logger, and is put into a Datalogger actor parameter as Fixed (read-only) text. The issue with the span fileUpload process not always working remains, and so for now a couple tries are made before giving up. Site import is now slower because of program retrieval (esp. if retries occur), but I think it's worth it.

Actions #9

Updated by Derik Barseghian about 13 years ago

This new feature can sometimes crash cr1k_d, so I've temporarily disabled it at r27619.

Example crash:
  • glibc detected * ./cr1k_d: realloc(): invalid next size: 0x412031a0 *
Actions #10

Updated by Derik Barseghian over 12 years ago

Changing target, this feature will probably have to stay disabled for the first sensor-view release.

Actions #11

Updated by Derik Barseghian about 12 years ago

The g++ I'm using on Lion gives some good warning messages that I don't think I've seen before, including about the method that gets the logger program. Look into these

Actions #12

Updated by Redmine Admin over 11 years ago

Original Bugzilla ID was 4763

Actions

Also available in: Atom PDF