USA Cal Club: Round 2

[CatalinaWOW]

Rejecting Excel on proprietary grounds while proposing Google sheets is inconsistent. 

?
What should be "inconsistent" with both proposals if they have nothing to do with each other?

I've seen excelsheets, with rudimentary macros, that only provided their functionality under an original ms-excel. (edit:) Not to mention when using different OS.

That's one thing.

Google-sheets is a cloud service, which could be very handy under certain circumstances, and is therefore used by many people when they work together on the same sheet locally. CSV-format has nothing to do with neccessary access grants, that we need to do that.

One was a hint, the other was a tip. What we can do with it, we are just beginning to see.

I agree with the dangers of compatibility with Excel sheets containing macros, and definitely anything with VB functionality.  But your comment recommended staying away from proprietary software (although you did go on to speak only of open formats for documents).  Google Cloud is definitely proprietary and could go away, become restricted, or become a pay service at any time.  And that is the basis of my inconsistency comment.  Even though I do agree that they are somewhat different services.  (There are collaboration tools in the Office products.  How well they work depends on the work style of the teams using them, and they are certainly not the be all and end all of solutions to the collaboration problem.  I haven't found cloud products to be that solution either, though they do definitely have their merits.)

I am not a zealot on Open Source, but find that many people are, and I therefore sometimes read more into comments on proprietary software than was intended.  I apologize if you were in any way offended.

[TiN]

I can expose mercurial repository for data/plotting and everybody can contribute there, while everything will be automagically redundant and decentralized, not relying on single weak point/server/person. 

[hwj-d]

...
I am not a zealot on Open Source, but find that many people are, and I therefore sometimes read more into comments on proprietary software than was intended.  I apologize if you were in any way offended.

That's ok. We are not on an ad hominem side of discussion. That's not the problem 

Problem was, that the statment/cognition of part one in same thread, MS-Excel with all massive inherently problems, was transferred to the second completely independent proposal to use collaborative table software, which even seems to be particularly suitable for us, because a table kept centrally in the cloud, with subscriber-related rights can even be operated by web browsers. I've rated excel to that, but not google-sheets. You can't criticise inconsistency if consistency is not intended that way.

To be honest, I'm a little surprised by the headwind when I call ms-excel less suitable for us for the known reasons, when there is much more flexible and unrestricted software available everywhere like LibreOffice.

[rhb]

It's here!!!

Many thanks to all.  Very nice set up.  time for me to switch from mechanical engineering to electronics.

@bitseeker.  Can you make a PDF of the instructions?  I'd like to print them out and put them in the box when I send it out.

FWIW I started a group, machine-tool-rebuilding@groups.io as I got fed up with being trolled by people who could not pass a high school  graduation exam.   I have been amazed by the number of machine operators who claim to be "machinists" but are unable to solve practical problems in algebra, geometry and trigonometry.

WRT the spreadsheet stuff, a good  friend from grad school who is now a professor at Drexel has published a number of professional papers about mathematical errors in Excel.  I don't use Excel, but after many conversations with him about the subject, I would not trust Excel as far as I could throw my Ford Ranger.

[bitseeker]

@bitseeker.  Can you make a PDF of the instructions?  I'd like to print them out and put them in the box when I send it out.

I tried several different ways of generating a PDF from the User Guide thread, but none of them are ideal (images are too small, includes forum formatting, includes extra posts at the end, shows ad at the top, etc.). I tried Firefox's "simplify page" feature, but it only includes the contents of the first post. The worst, though, is the forum's built-in "Print" feature — it removes all the images!

Any ideas how to do a good conversion to print without having to maintain two separate copies of the guide?

[hwj-d]

@bitseeker.  Can you make a PDF of the instructions?  I'd like to print them out and put them in the box when I send it out.

I tried several different ways of generating a PDF from the User Guide thread, but none of them are ideal (images are too small, includes forum formatting, includes extra posts at the end, shows ad at the top, etc.). I tried Firefox's "simplify page" feature, but it only includes the contents of the first post. The worst, though, is the forum's built-in "Print" feature — it removes all the images!

Any ideas how to do a good conversion to print without having to maintain two separate copies of the guide?

Wrong workflow.

Nothing against your work. But in my opinion the forum software is not suitable for a PDF export of a single post, and not even intended for it.

The right way under these circumstances would have been to link to a PDF from the very beginning to avoid duplicate work.

[bitseeker]

hwj-d,

I completely agree and was hoping that, having already gone down this road, I'd not have to backtrack. I never expected the guide to be a physical document. Otherwise, I'd have started it in a word processor.

All,

So, is it better to have the guide as a PDF attached to a forum post (better for printing, but must be download to read)? If so, I'd rather redo it before adding more content.

What say ye? PDF or online?

[CatalinaWOW]

I would vote pdf for a number of reasons.  Perhaps most important, by starting with a document processor you will have much better tools to create the content.  Should be easier on your end.  Also will make it easier to collaborate or pass on the task when life inevitably intervenes.  Another is on the receiving end.  While I have a laptop near my instruments for data logging, it really is more convenient to page through a document while setting up.  The document takes up less space than a laptop, can be moved around easily, is far less finicky about the surface it sits on and doesn't require as much worry about possible damage.

[RandallMcRee]

PDF for same reasons as CatalinaWow.

Also, lets go with csv as the universal data exchange format. We all have tools that ingest them....

[bitseeker]

Yes, CSV.

[rhb]

OK, it's showtime!

I've got my bench cleared of the 6" of debris that has covered it for the last few months,  printed out and read the Tempduino source once and booted a Windows machine with the Arduino IDE on it.

The Tempduino seems to be giving reasonable values.  I'm in a 7' x 10' closet with a 6000 BTU window unit running at low fan speed and set as cold as it will go.  The door to the rest of the house is open.

The Tempduino on the bench reports ~69.6 F and the WWVB clock about 3 ft higher reports 74.3 F.  I've moved it to the bench top and it seems to be moving lower as the Temduino moves higher.  I've also got a Sunbeam analog temperature and humidity gauge on the bench.  None of these have *any* pedigree.

The room is cool enough I'm wearing an insulated vest.  There are now 3 Z400s and an LCD monitor running.  Outdoor temp is around 90 F and it's quite humid.

So now it's time to learn to talk to the Tempduino by USB.

Have Fun!
Reg

[rhb]

I *think* I might have fixed the Tempduino.  I explicitly reset the accumulators just before the averaging  loop using another Uno I had so I did not disturb the one I received.  If I understand loop(), that should not be needed, but C++ does "interesting" things when you least expect it.

I need to log data for 24 hours which Arduino 1.8.5 doesn't support  that I can see.  At the moment I'm using Windows 7 which is very much a foreign land for me.  So I'll probably switch to Debian 9.3 to use the Python stuff.

I'm going to try to find a case for the Tempduino.  If I can find it, I have one which should be the right size.  Unfortunately, it is brutally hot here and even 5 minutes of looking through boxes leaves me soaked, so I need to get lucky.

Reg

Edit:  Thanks to the wonders of Cygwin I am now logging data to disk *without* being forced into mortal combat with the computer ;-)  I'll post a graph in the morning.

Where can I find hardware details?  The LCD board is different from mine and I don't have one of the Si sensors. So rather than delay shipping the kit to the next person while I make a case, I think it makes more sense for me to just make another one in a proper case and swap them out later.

[rhb]

I think it's fixed.  Here's a plot  of data from running all night. 

It appears that it is quite sensitive to when I am in the room.  I'm just using the serial port to log data to a file adn plotting it with gnuplot.  So I don't have time stamps.  I'll get python working on Windows if I can.  If not I'll switch to Debian and log the data there. 

It seems to me that adding an RTC to the Tempduino would be a nice feature.  I've got one and am willing to do that, but I don't want to delay sending it to the next person.  So I suggest that after I cal my DMMs I send the existing unit out with just the code change and then send out a Tempduino Mk II in a case with RTC later to join the kit.

[rhb]

Is there a document that describes how to properly perform a calibration for particular equipment models?

It would be very helpful if one knew with certainty that they were setting up the meter properly.  I have a pair of 34401As and a pair of 3478As to calibrate, but *no* confidence at all that I know how.  I've never read the entire manual for either, and even if I had, I've been deep in mechanical engineering land for the past few months trying to get my head around such subtleties as the deflection of non-circular beams under combined torsion and point loading.  That's *very* different from  the mechanics of porous media and fluids.  I've learned that it is all too easy to forget to do something if you have not done it in quite a while.

A checklist of settings and work procedure for each of the common instruments would help ensure that each person gets the most out of their time with the cal kit.  It would be pretty heartbreaking to realize the day after you shipped it out that you had set something wrong.  I'd feel a lot better if TiN or Andreas had reviewed my workflow for correctness.

Now to get the GPIB adapter hooked up so I can log data from the instruments.  I'll be logging the room with the Tempduino while I work on that to make sure that I really have fixed the bug and will post the full series logging for 24 hours this evening.

Have Fun!
Reg

[Kosmic]

I *think* I might have fixed the Tempduino.  I explicitly reset the accumulators just before the averaging  loop using another Uno I had so I did not disturb the one I received.  If I understand loop(), that should not be needed, but C++ does "interesting" things when you least expect it.

Not sure what you mean. Technically the accumulators are already reset on line 29 and 30 at the begenning of Loop(). Also since those variables are allocated on the stack they are going to be deallocated when the function exit. So next time Loop() is called the 2 accumulators are going to be re-allocated and set to 0 at the beginning of the function.

See https://gist.github.com/cellularmitosis/7249b64a3b58010b7955e83dccb60e97#file-thermometer-ino

[rhb]

I *think* I might have fixed the Tempduino.  I explicitly reset the accumulators just before the averaging  loop using another Uno I had so I did not disturb the one I received.  If I understand loop(), that should not be needed, but C++ does "interesting" things when you least expect it.

Not sure what you mean. Technically the accumulators are already reset on line 29 and 30 at the begenning of Loop(). Also since those variables are allocated on the stack they are going to be deallocated when the function exit. So next time Loop() is called the 2 accumulators are going to be re-allocated and set to 0 at the beginning of the function.

See https://gist.github.com/cellularmitosis/7249b64a3b58010b7955e83dccb60e97#file-thermometer-ino

That's what it is *supposed* to do, but there is no guarantee that loop() is actually a function.  Once I have a 24 hour run with the modified version I'll put the kit Uno back and log another 24 hour run.  If the 2nd run shows the glitches then it is fixed.  I just looked at the data and it still looks good.  No glitches, so let's hope.

I couldn't find any documentation for the GPIB-USB interface in connection with WavyDipole.  Google just handed me links to the NI and HP units.  I was about to ask,  but had the wit to look at the board and found the documentation which I just printed.  We need to add a link in the Cal Club 2 user manual to the Twilight-Logic/AR488 page.


I'm still looking for instructions for checking my 3478A and 34401A DMMs.  In particular, would it be OK to connect both the 34401As to the PX at the same time?  That would cut the amount of time I need to keep the kit in half.

TiN?  Andreas?

[rhb]

It's probably not quite a full 24 hour record, but it should be good enough.

The broad spikes are the result of my physical presence and the heat from the LCD monitor.  It was 95 F before noon today here, so things look correct for a 7' x 10' closet on an ouside corner wall, a 6000 BTU window unit, three Z400s running  and some fool wandering in to mess around on a computer from time to time.

I'm going to shutdown and switch to the Uno with the original code to verify that it really was a bug in the Arduino toolchain and not an environmental problem at @bitseeker's location. The original code is correct as I've documented in a thread in the MCU section.  But the Arduino IDE didn't do what it was told.

I'm madly reading the EZGPIB, 3478A and 34401A  documentation and hope to start making calibration runs tomorrow.

Have Fun!
Reg

[bitseeker]

Is there a document that describes how to properly perform a calibration for particular equipment models?

It would be very helpful if one knew with certainty that they were setting up the meter properly.  I have a pair of 34401As and a pair of 3478As to calibrate, but *no* confidence at all that I know how.  I've never read the entire manual for either, and even if I had, I've been deep in mechanical engineering land for the past few months trying to get my head around such subtleties as the deflection of non-circular beams under combined torsion and point loading.  That's *very* different from  the mechanics of porous media and fluids.  I've learned that it is all too easy to forget to do something if you have not done it in quite a while.

A checklist of settings and work procedure for each of the common instruments would help ensure that each person gets the most out of their time with the cal kit.  It would be pretty heartbreaking to realize the day after you shipped it out that you had set something wrong.  I'd feel a lot better if TiN or Andreas had reviewed my workflow for correctness.

For calibration procedures, you need to get the service manual or calibration manual for the specific device you're calibrating. Also, you'll need references for all the ranges unless you only want to calibrate the one voltage and two resistance ranges covered by the current kit.

I couldn't find any documentation for the GPIB-USB interface in connection with WavyDipole.  Google just handed me links to the NI and HP units.  I was about to ask,  but had the wit to look at the board and found the documentation which I just printed.  We need to add a link in the Cal Club 2 user manual to the Twilight-Logic/AR488 page.

Links to the documentation, project page, and forum thread are in the User Guide under AR488 GPIB Interface.

I'm still looking for instructions for checking my 3478A and 34401A DMMs.  In particular, would it be OK to connect both the 34401As to the PX at the same time?  That would cut the amount of time I need to keep the kit in half.

Set both 34401As to 10GΩ input and you can connect them both to the PX reference in parallel. A net 5GΩ input will be fine.

It's probably not quite a full 24 hour record, but it should be good enough.

The broad spikes are the result of my physical presence and the heat from the LCD monitor.  It was 95 F before noon today here, so things look correct for a 7' x 10' closet on an ouside corner wall, a 6000 BTU window unit, three Z400s running  and some fool wandering in to mess around on a computer from time to time.

That behavior looks normal to me.

I'm going to shutdown and switch to the Uno with the original code to verify that it really was a bug in the Arduino toolchain and not an environmental problem at @bitseeker's location. The original code is correct as I've documented in a thread in the MCU section.  But the Arduino IDE didn't do what it was told.

I'm also looking forward to seeing if the problem returns with the original code. It should as I haven't seen this kind of anomaly with the previous temp sensor we used for the kit.

[bitseeker]

It seems to me that adding an RTC to the Tempduino would be a nice feature.  I've got one and am willing to do that, but I don't want to delay sending it to the next person.  So I suggest that after I cal my DMMs I send the existing unit out with just the code change and then send out a Tempduino Mk II in a case with RTC later to join the kit.

That sounds cool. You could send it to vindoline since he'll have the kit after each member is finished.

[Kosmic]

I *think* I might have fixed the Tempduino.  I explicitly reset the accumulators just before the averaging  loop using another Uno I had so I did not disturb the one I received.  If I understand loop(), that should not be needed, but C++ does "interesting" things when you least expect it.

Not sure what you mean. Technically the accumulators are already reset on line 29 and 30 at the begenning of Loop(). Also since those variables are allocated on the stack they are going to be deallocated when the function exit. So next time Loop() is called the 2 accumulators are going to be re-allocated and set to 0 at the beginning of the function.

See https://gist.github.com/cellularmitosis/7249b64a3b58010b7955e83dccb60e97#file-thermometer-ino

That's what it is *supposed* to do, but there is no guarantee that loop() is actually a function.  Once I have a 24 hour run with the modified version I'll put the kit Uno back and log another 24 hour run.  If the 2nd run shows the glitches then it is fixed.  I just looked at the data and it still looks good.  No glitches, so let's hope.

The only way for Loop() to not be a function would by adding "static inline" in the definition. The compiler doesn't really have the choice, the way Loop() is defined, it's a function. I can re-create a small example here and show you some assembly code if you don't believe me 

[rhb]

@bitseeker  Hopefully we'll have a definitive answer on the glitches in the morning.  I've got all the other stuff.  It's just a lot to digest quickly.  I'm  raising a lot of this for the benefit of the community as a whole.  Someone might get the kit and then get slammed at work and try to do a cal without enough time to think through what they need to do.  There's a good reason pilots have checklists.

The plan is to send the new temperature and humidity logger to @vindoline when it is ready.  I'm thinking about using either an MSP430 or an ESP32 for it so it can log to an SD card in transit.  I've got a couple ESP32s, but zero experience doing anything with them. I can do a code review a *lot* faster than I can digest datasheets and code for a new processor.  So if someone is proficient in coding the ESP32 I think a WiFi logger would be really nice.

I'd bet that between them TiN and Andreas have one or two of everything of significance.  And the two of them have more experience (aka have made more mistakes) than all the rest of us combined.

@Kosmic   I can transform *anything* into *anything* (edit: natural languages excluded).  And that's without taking into account what a compiler does.  I rewrote 500,000 lines of VAX FORTRAN into standard FORTRAN 77 with custom function calls to replace the VAX run time library calls.  It took me about a week to write the program, but it worked flawlessly and was *much* faster than doing the edits by hand.  It was also completely reliable which hand edits of that scale are not.

I have routinely transformed C89 into FORTRAN 77 if I discovered I needed to do complex arithmetic.  Yes, C99 will do complex arithmetic, but it's ugly.   I prefer to use carpenter's hammers for nails and mechanic's hammers for machinery.

Please feel free to investigate what the Arduino IDE is actually doing and report on it.  I'd really like to know.  So please take a look at the temperature plot I post tomorrow.  If it's got the same glitches @bitseeker reported it needs to be fixed by the Arduino maintainers as it violates the language standards as I documented in the MCU forum.

Have Fun!
Reg

BTW if you ever feel that people are unpleasant here, try practicalmachinist.com or the 7x12minlathe@groups.io list.  I greatly admire machinists, but have concluded that the majority of those claiming the title are mere machine operators who have been turning wrench handles for 30 years.

[Kosmic]

Please feel free to investigate what the Arduino IDE is actually doing and report on it.  I'd really like to know. 

https://github.com/arduino/Arduino/wiki/Build-Process

Long story short, they call your Setup() and Loop() functions from a main() and compile everything with GCC.

Should look a bit like that:

Code: [Select]

void main()
{
    Setup();

    while(1)
    {
        Loop();
    }
}

So I really think the glitch come from something else.

[bitseeker]

Please feel free to investigate what the Arduino IDE is actually doing and report on it.  I'd really like to know. 

https://github.com/arduino/Arduino/wiki/Build-Process

Long story short, they call your Setup() and Loop() functions from a main() and compile everything with GCC.

Should look a bit like that:

Code: [Select]

void main()
{
    Setup();

    while(1)
    {
        Loop();
    }
}

So I really think the glitch come from something else.

Yep, that's how I understood it. It's just a normal C program with a wrapper to "hide" main(). I have yet to understand how it's any simpler to someone new to programming. The IDE could've just put a normal code skeleton with two empty blocks for setup and loop. But I digress.

I'm also looking forward to the unveiling of where the glitches are coming from, even if it ends up being my non-temperature-controlled environment. (Ah, yes, it was those pesky neighbors welding in the middle of the night. )

[bitseeker]

@bitseeker  Hopefully we'll have a definitive answer on the glitches in the morning.  I've got all the other stuff.  It's just a lot to digest quickly.  I'm  raising a lot of this for the benefit of the community as a whole.  Someone might get the kit and then get slammed at work and try to do a cal without enough time to think through what they need to do.  There's a good reason pilots have checklists.

Yep, agreed. I'm happy to incorporate anyone's checklists into the guide and include attribution. Just let me know how you want your name to appear with your contributed content.

[rhb]

I just looked at the data after switching to the Uno from the kit.  I don't see any glitches.  I *should* have made note of when I changed over, but did not.  But I'll know in the morning.

It's entirely possible it was EMI, but the regularity makes that difficult to believe.  If it is not resolved before I send the kit back, I'll send the Uno I programmed along with the original so if the glitch reappears it's just a board swap to test the software change and we don't have to deal with different compiler versions, etc.

I think it's very important that until we resolve the actual cause we do *not* modify the FW on the Uno @bitseeker was using.

I already have far too much scar tissue from dealing with this sort of thing.  At least in this case, I don't have a bunch of high level managers looking over my shoulder asking if it's been fixed yet. 

I had that happen once when  a program I wrote tickled an undocumented edge condition in X11 and would lock up user systems at random. I spent a lot  of my time for a very painful week on the phone with top level Sun support trying to resolve that. In the end I made a wild guess it was an obscure race condition in X11 and made a small change to the order of operations in the code which solved the problem.  Sun support was throwing possible fixes at me as fast as I could test them.  I just happened to solve it because I got lucky first. The thing that really made me crazy was *most* of the time it worked properly.  But I was working at the very lowest levels of X11.  I never did figure out what the issue was, but very likely it was a X11-CDE/Motif interface bug.

I've fixed lots of major problems with other people's code.  That was the only one I wrote and it stung.  I've always taken great pride in getting it right first time, every time.

This sort of stuff is *not* fun,
Reg