Neil Pate

Nice spot. It is a perfectly valid character though.

Anyone want to guess what happens if you try and copy and paste the contents of this string to some other application like Notepad? String Copy Weirdness.vi

Yeah sorry I did not mean to derail things. That sounds really cool and the more VIMs we get into the community the better.

Total thread derailment... Hands up who remembers the great error cluster colour change. Was it 2005?

I now lump Network Streams in the same category as Network Shared Variables; generally more trouble than the benefit they offer for the various reasons captured above. I now prefer to do this kind of thing "manually" using the low level TCP/IP prims.

Thank you, I did find the service request I opened. Turns out I was mistaken and it never got escalated to a CAR. Sorry @joerghampel For what it is worth, on a different PC I have not seen the same problem, so I think it might just be down to a bad install of LabVIEW. Super annoying though!

Would love to, but I cannot find it in my email 😞 Do you know if my CARs are listed somewhere on my ni.com profile?

@X___good luck. I had exactly this problem when joining my new company. I went around the houses over and over with NI, most of the support staff had no idea what was going on. I am not sure it was ever resolved. In the end I managed to get through to a human via email and they were able to help me with my technical question.

I think an important point has been missed in this discussion. The fact that the solvent name and density make up a "collection" of information (i.e. a data type). @Mahbod Morshedi if you don't already know about them go an read up about Clusters in LabVIEW. They allow you to make custom data types where you can group together related elements. Maybe even a Set would be an interesting implementation here where you can look up the density by using the name of the product. Don't be tempted to grab into your GUI to get at your data (i.e. reading from a combo box to get the density). Rather store the data somewhere else (on a wire) and just access it as you need to.

Disclaimer: this is some time ago so my memory is pretty foggy! I had some very strange crashes on bunch of cRIOs in a lab. Eventually after much trouble I diagnosed the problem as being related to setting the system time! I had a routine that tried to sync all the cRIO clocks and every now and then the call to the System Configuration VIs would hard crash a system. I never actually saw it happen with my own eyes but I have enough evidence to be able to blame it on that. I cannot recall exactly how I solved the problem in the end, I suspect I slowed down the rate at which the clocks were set. As I said, this was a long time ago though and the cRIOs were probably not running RT-linux. You mentioned you have a GPS module, so maybe just maybe this is related?

After getting burned by the system with the USB cameras I switched over to GigE and never looked back. Multiple USB cameras running at full frame-rate is a recipe for disaster!

Thanks! Mine has definitely wandered off.

Am I losing my mind? I cannot find the VI Server property to change the visibility of the Toolbar. I know I can do this in the build spec, but I want to be able to force this off in an executable. I am being dumb, and it's obvious, right?

Sorry @FixedWire, I took a look at my old code and indeed I have LabVIEW code to read a hex file, not to generate it.

I have done something like this years ago. I will see if I can dust off what I have. My memory could be totally faulty though!

Thanks, that is a nice project; I had not seen it. I found a C64 implementation, but this Apple II one is nicely structured.

Got it, thanks. This is a bit annoying, but I can use the technique @ShaunR suggested with the mask. I am busy making some kind of weird C64 with a real 6502 but ROM and RAM (and I guess VIC-II) faked in LabVIEW, so the speed is going to be terrible!

I cannot really see the pattern though. These have the anti-aliasing But this doesn't and surely has similar groups of pixels

Further experimentation shows me this weird effect happens as soon as you go above 1 for the ZoomFactor. Even sticking with integer values for ZoomFactor causes it to happen as soon as ZoomFactor is > 1

That looks like a pretty broken anti-aliasing algorithm then! You are right, I have the ZoomFactor cranked up to 25, but this really should not cause any kind of anti-aliasing. Anyway, I don't want the picture control to do AA, this just seems strange to me. Dropping the ZoomFactor down to 1 and then taking a screenshot (and then zooming in) shows it is actually working fine, so at some point the ZoomFactor must be screwing it up. Interesting...

I am playing around with the character ROM from a Commodore 64. Extracting the contents and converting to bit arrays Say I have this bit patten, and I convert it to a U8 [][], like this Then I can display it on a Picture Control, no problems Like this So far so good... Now does anyone know why this particular pattern (and a few others) don't work correctly? As you can see in the picture I am getting some light pink leaking through (almost like some kind of anti-aliasing). It does not happen for any of the alphabetic chars, but does for a few others. Any ideas?

Yeah... But now pretend it's 1963. This is clever.

Today I Learned... you can convert from upper case to lower case like this! Clever design hidden in plain sight. See for yourself

Also I think the Mean VI coerces the inputs to DBL. This is not always desirable. Maybe time for a native VIM?

Toggl is free. They do have a paid for tier which I tried for several years, but the free tier is perfectly usable for simple things.