Jump to content


  • Content Count

  • Joined

  • Days Won


ShaunR last won the day on August 12

ShaunR had the most liked content!

Community Reputation


About ShaunR

  • Rank
    LabVIEW Archetype

Profile Information

  • Gender

LabVIEW Information

  • Version
    LabVIEW 2009
  • Since

Recent Profile Visitors

16,167 profile views
  1. Raw TCP. Make your application respond to SCPI commands and the other engineer can treat it like any other instrument. Can even be over a network (remote). It's a simple method which is programming language independent and can be added to existing applications without much problem. Also has no additional installation or distribution requirements.
  2. I don't know what the original file was but you are more than welcome to use the mine, if it is similar. Rolling Average.vi
  3. Well done for volunteering I look forward do testing it
  4. Nice. It's screaming out to be made into an xControl, IMO.
  5. When the compiler doesn't care, why should I? The view I take is that "Style Guides" are just that. GUIDES, not LAWS. If "boolean" was chosen, what do you do about capitalisation at the beginning of a sentence? There are arguments for grammatical considerations but I'm "meh" when it comes to programming type names, classes at. al. These things are just a distraction - form over function. Read it and weep:
  6. This is a historical "problem" due to compilers being case sensitive. This was one of the reasons that I went for Pascal compilers over C since Object/Open/Turbo Pascal is case insensitive and boolean or Boolean are synonymous (as a type). I've always maintained that there is no excuse for case sensitvity as it only introduces errors, obfusicates and increases foot-shooting but has zero benefits (unless you consider obfusication a benefit which is arguably a security risk). I've had many conversations with C/C++ programmers over capitalisation of types and function names (initial caps vs camel case vs lower case etc) and my response has always been "whatever". Do we really need to bring this problem to a wiki, of all things, about a language in which case is irrelevant?
  7. I can't substitute terms because you defined a specific architecture as the generic "message" - with which I disagree. OP: Just for fun and giggles. Turn on "Synchronous Display" on the indicators.
  8. I disagree with this characterisation. The losslessness is not a citeria for being a message-based system or not - nor is central handling. Put simply. Messages are just descriptors with or without data and a "tag" is just a message without data.
  9. Transmittion of data at a rate (Hz) is not very conducive for ethernet. It is intended to move large amounts of data efficiently. Typically, ethernet connections use the nagle algorythm where data is transmitted after the accumulation of a certain number of bytes or after a timeout (typically 250ms). This is to solve the issue of small data packets flooding the connection (which is what happens at high rates with, say, a single double in the packet) If the nagle is turned off, then packet overhead comes into play and the network can start to behave irratically at high data rates. This is where ethercat comes into it's own. At least one week if you don't already have a solution in your toolkit.
  10. One aspect of reflective memory architectures is determinism. For that reason and without a full detailed spec, I would err on a reflective memory network solution (option 1). You may have to start looking at ethercat and synchronising asynchronous systems depending on the reasoning for the insistance of the reflective memory in the first device since you get that for free with a reflective memory network.
  11. I'd be interested to see a comparison with SQLite (Altenbach didn't post his code). Those times seem really slow for the number of entries.
  12. xControls are at timestamp 1:01:51
  13. In todays censorious climate (and YT copyright trolls). The trend seems to be to use Bitchute as an alternative backup.
  14. As everyone else is suggesting. Simulators are non-trivial and product specific. You pretty much end up reverse engineering the software in the device you are simulating. One method I have used in the past though is message capture. This works with TCPIP, serial and other similar devices. Basically you capture/record the message strings for specific control messages and play them back to your software-usually used for testing. If your software architecture is message based, then it's trivial to switch out the endpoint just by redirecting to the comms interface instead of a play-back VI and you don't suffer from the "bug in simulator vs bug in device" problem.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.