MFMP: Automated experiment with Ni-LiAlH

magicsound

I haven't executed the file but besides the version number the previously highlighted part seems the same: what changed and how?

In the end as I couldn't manage to rebuild the program from the source code I reverted to using a Java bytecode editor called JByteEdit to change strings directly in the "compiled" java files in the program .jar. I could easily change things like the version number and see the results immediately, but I'm unable to test if modifying the previously indicated date formatting string works as it seems to be necessary to have a working spectrometer to save new files with current dates.

Anyway this is probably starting to get a bit too off-topic. Also, it's the software producer who should be correcting this.

Hopefully a new ClamShell experiment will start soon.

This is a cool prospect. So, may I ask a couple of questions about this hack to the 24 hour format:

1. Does this put the 24 hour time in a place/way that all of the timestamps will use it? For example, will the multi- spectrum use it? Will the Data Report use it? When it outputs to the .csv format, will the new format get used? When a .spu file gets read in, will it understand the new format? If it is just a text record, then then it probably never gets understood per se.

2. What build(s) of USX will this new MCA_Stand_Alone.jar work with - the 32b version or the 64b version? My spectrometer only works with the 32b version of USX.

Quote from BobHiggins

1. Does this put the 24 hour time in a place/way that all of the timestamps will use it? For example, will the multi- spectrum use it? Will the Data Report use it? When it outputs to the .csv format, will the new format get used? When a .spu file gets read in, will it understand the new format? If it is just a text record, then then it probably never gets understood per se.

I think this should work for everything. From what I've seen the program doesn't really handle dates. It builds them onto a string. This string is then saved once into .spu or .csv files. When the program loads the date from these files, it loads a string, so it doesn't really know it's a date. This is how I believe it works.

Quote from BobHiggins

2. What build(s) of USX will this new MCA_Stand_Alone.jar work with - the 32b version or the 64b version? My spectrometer only works with the 32b version of USX

In theory Java bytecode isn't platform-specific, so the file posted by magicsound should work on both 32 and 64 bit versions. However, possibility exists that there are code-specific differences. I previously checked that file and the function I was talking about didn't appear to be changed, but I haven't looked in detail at what else magicsound has done to it.

In case it doesn't work you could use on your .jar file the JByteEdit program I linked in my earlier comment and search the string in the previously indicated class, then modify it yourself.

Here some useful examples are shown:

https://docs.oracle.com/javase…ext/SimpleDateFormat.html

By using this:

"yyyy-MM-dd'T'HH:mm:ss.SSSXXX"

You would obtain a date in this format:

2001-07-04T12:08:56.235-07:00

@Alan,

So did you just binary change the "hh" in the hour format to "kk"?

The correct (and less intrusive) way would be making them two capital 'h' i.e. "HH".

EDIT: I just noticed after checking again that this is indeed what magicsound did; maybe I previously read the wrong file or overlooked it because I thought he would change the date to a more standard format. Sorry.

BTW, yesterday I got the new reactor tube assembled and epoxied. Today curing will complete and the tube will be assembled into the system for the calibration run. Hopefully I can start the calibration run tonight.

BobHiggins

Do you plan running the calibration live or eventually posting the data? I'd like to test a few things with calibration data.

Quote from can

The correct (and less intrusive) way would be making them two capital 'h' i.e. "HH".

EDIT: I just noticed after checking again that this is indeed what magicsound did; maybe I previously read the wrong file or overlooked it because I thought he would change the date to a more standard format. Sorry.

Yes, I used XVI32 to change all five occurrences of "hh:mm" to "HH:mm". Then I changed all occurrences of the version string to "1.2.24H". I've used this kind of binary hack in the past, and it usually works if the binary doesn't use a checksum or similar ECC mechanism. There is something tricky in the USX launcher, probably a file path detail. But if the hack is done in the same directory as the USX launcher, it seems to work.

As far as the 32bit/64bit issue, I can't say - I only tested it with the version I have installed.

can,

I can post the data live. I will make a new Google drive folder under the same tree. I will post you with the details when I start it. I am going to fix the 2nd+ file missing character in the header bug in Labview before starting this. I know just where to fix that one.

BobHiggins

Nice.

I don't think that a link to the root folder has been previously posted, however.

Ok, the post-calibration run has started. The files are going into a folder called, "PostCalibration" under the same parent folder containing the data from the last experiment. It will be an hour before the first .csv file of data will be dropped into Google drive. Calibration will step beginning at 100C, in 50C increments to 1200C, and then will step down in larger increments. There will be a 1 hour stabilization soak at each temperature. The overall calibration will take 32 hours.

I believe I have fixed the bug in the Labview code that caused the first character in the header of the 2nd and successive .csv files to be missing. Hopefully, that problem is now gone.

Link to parent folder: https://drive.google.com/drive…RwT0RFeGVjTjQ?usp=sharing

BobHiggins

Thanks. I thought you meant to post a link to a parent folder which contained these folders (and perhaps new ones):

https://drive.google.com/drive…Pc25a4cOM2aHV4dkw0eENjMjQ

https://drive.google.com/drive…Pc25a4cOM2dERwT0RFeGVjTjQ

By the way: with the option "add to my drive" it's possible to link these folders in one's own Google Drive account:

By doing this it's easy to sync their contents locally with the Google Drive app. This means that updates will be automatically received.

can,

I have thought about automatic synchronization, but I am concerned about the file that is being appended once every minute or so. I am worried that the Google sync will somehow cause contention for the file and crash something. What I want to do is only copy across completed files.

BobHiggins

There's a misunderstanding: I mean that users can automatically synchronize on their PC the contents of these shared folders, like I have been doing so far.

In other words, it's a tip I'm sharing, perhaps not everybody knew about it.

BobHiggins

I'm trying to experiment if it's possible to compute the calibration coefficients automatically. I managed to do it with the "simulated" data, but it's not clear if it will work with real data.

polyfit coefficients: [ -1.96640299e-06, 1.00296579e+00, -1.18176228e-01]

can,

That's neat. It is a lot of work to extract the data manually, that's for sure. I did it manually from the previous data. The easy part is the least squares fit. The hard part is searching the data for the settled sections of temperature and getting the power at the settled temperature. I am adding another folder that had the previous calibration files for testing your code. It is the folder, "PreCal-NotApplesToApples".

The second file has now come out and the problem with the missing characters in the header seems to be repaired.

EDIT: Maybe I found a way, but it's ugly and not really usable yet.

EDIT: anyway, here's a quick graph for that calibration run (2017-03-11). DC Power didn't seem to have completely stabilized at higher temperatures:

I tried to test the same method with the ongoing calibration run:

can,

You could extract the elapsed times where the steps begin and end from the driving script. Then you could just back off a few seconds before the next step and average about 1 minute of data to get the settled power.

I added the overnight points a few minutes ago. Now at 900C.