3devo / dvconnector Goto Github PK

This file can now collect quite some data, so it should probably be limited in some way.

As the title suggests, this simplifies the amount of generated files. Especially when the extruder has been stopped in the meantime or if the USB-cable has been accidentally disconnected.
Logging by date/time is indeed useful only for that same day/extrusion session, appending data from one day to another day's file could cause confusion by the user if appending is done without notice.

I think that the following things should be done to avoid confusion and make this feature more useful:

1. Files may be appended only for files on the same day or within a few hours, mainly because this would be a whole new extrusion session.
2. Appending may only happen when asked by user.
   a) Mainly because users will know that it will be added to the same file(prompt notification with the "last known/previous" file name).
   b) When users decline from appending to the "last know" file. It should create a new file with a new timestamp. You might need to make it clearer to where the date and timestamp splits up, because ".Format("2006-01-02-15-04-05")" is very annoying to read with all the same separators("-"). Maybe a format like this ".Format("2006-01-02@15-04-05")" or underscore is recommended.
3. Later on we can even let the user determine the format of the timestamp in the filename, but this would be an additional feature later on(e.g. "Name_"{YYYY-MM-dd@HH-mm}).

Yesterday, we had a long running logfile, that showed a gap of about 10,000 seconds halfway. Reasoning back, it seems likely that the computer went into standby mode, causing a chunk of log output to go missing. Looking at the computer power settings, it was indeed set to go into standby mode after 2 hours, so that is probably the cause. When this happened, the frontend seemed to have disconnected from the connector as well.

It would be interesting if the connector could somehow prevent the computer from going to sleep. I suspect there are OS-depenent APIs for doing so. If we do this, it should probably be configurable (but default to on).

Another interesting observation is that with manual logging with the Arduino application, this problem never showed up. So perhaps Arduino is already doing something similar, or perhaps the fact that it is showing and updating a window is sufficient to prevent standby?

Sometimes, a build produces a connector that fails to resolve the / url and turns it into an infinite redirect. IIRC it redirects / to /../ or ../ (which the browser flattens to //) which redirects again to the same place.

At one point, @HendryKaak saw this in (I think) a release build, but when he did a development (non-packr) build with extra output, the problem went away and was no longer reproducible.

Today, I had the same problem in a development build, and the problem stayed around, so I dug in. I've found that:

• The redirect is generated by net/http's FileServer (which is used as the 404 handler for httprouting).
• The FileServer delegates the '/' (or perhaps '' by then) url to packr's Box::Open. This returns a file (rather than a directory), which I believe prevents net/http from looking for /index.html. This is gobuffalo/packr#173. It also causes it to prepend ../ and redirect, which it apparently does if a request for a file ends with / (though I can't quite understand why prepending .. would be useful).
• There is some code inside packr that does the index.html resolution, but I think it does not (always) work (and also that it is the wrong place to do this).
• There is another problem with packr that makes it look outside of the box (at least in development mode). I reported this in gobuffalo/packr#192. Looking through the code makes me wonder if packr is really as clean in resolving lookings as it should be, so possibly this is also involved.

I'm not entirely sure why this happens sometimes but not always. My best guess would be that it happens if packr2 build was never run (so there is no packrd subdirectory with a bundled frontend). Once that is run, I suspect subsequent builds will use the bundled version, hiding the problem. This does not explain why @HendryKaak saw this in a production build, generated with packr build, though (but perhaps there are multiple problems with the same symptoms).

The UI just shows "Enable the machine, Press the dial on the device to start logging" and when you press done, the spinner in the connect button just keeps spinning.

Currently, when an instance is already running and another one is started, the second one fails to lock the database and exits. If the first one somehow lost its systray icon, there might not be any normal way to stop it. Also, the user might expect at least another browser window to pop up when they start the application again.

I guess we can handle this by letting the second instance connect to the first one through HTTP or something like that, though it might need access to the JWT secret to authenticate (which won't work if the secret is inside the database). Or perhaps it could somehow figure out the process id of the first instance and kill it? Maybe something else?