Jump to content

LogMAN

Members
  • Posts

    655
  • Joined

  • Last visited

  • Days Won

    70

Everything posted by LogMAN

  1. In most cases our customers have their own security measurements in place or the computer is not even connected to a network. All systems just have the standard Windows installation or the computer is setup by the customer in advance. We worry more about the person in front of the computer rather than the one outside a multi-layer firewall system. We don't. If the data is corrupted, the application fails and goes into error-mode. It then requires administrator privileges to continue working. This often means that me or one of my colleagues has to immediately find a solution. In the mean time the system will work in emergency mode without network communication. This of course is only valid if the customer wishes so, in other cases the application will reset itself and start over. None in particular from the outside world. When it comes to the operators they attempt to manipulate a system to blame it for productivity loss. Passwords. In the past we actually stored passwords non-encrypted into INI files. You can guess what happened No. Never have and never will. I wouldn't even give them encrypted data. Data I don't own will never be uploaded anywhere deliberately; that's thankfully a company policy which is why we have our own servers providing encrypted cloud support (to send or receive sensitive data through secure connections).
  2. The most irritating part of people saying "You should learn a real programming language like <insert language here>" is how none of them (at least in my experience) ever worked with LabVIEW more than a few hours. Some even say stuff like that after seeing code in LabVIEW the very first time. Now to your question: I guess it does not hurt to understand the basics of textual languages. With the knowledge you can even give advice to people spouting stuff like above (I like how they hate it ). A few years ago I watched the video series from Stanford on YouTube (Programming Paradims and Programming Methodology) which are really great and gave a good insight on how a computer actually works. I recommend looking into them. I don't program in C though (by far to slow for me ) instead I've learned C# which is very useful when testing .NET components (or even writing one to use in LabVIEW). In the end my programming in LabVIEW did not change much, just the opposite, LabVIEW changed the way how I wrote programs in C# Maybe all the textual programmers should consider learning 'G' instead
  3. I work very much the same way you do, but luckily no problems so far. In my case the keyboard is rather far away. My entire forearm is on the table such that the elbow is at the edge of the table and the keyboard is turned right (about 20°) to make it easier for the left hand. For the pressure on your wrists a flat keyboard might help (with a large wrist rest tilting down). My own is a terra keyboard 5500 (pretty old but extremly well made).
  4. LabVIEW (or rather 'G') is entirely flow-based, so this makes sense. This answers my question to some extend. I actually like to define boundaries between things as clear as possible in order to make my sources accessible for the other developers in my team. So as an example: If my Actor acquires some data and provides it for the outside world, it might have its own visual representation and maybe you can control it (so basically MVC in one Actor). On the other hand I require multiple visual representations to fit the data on different screen resolutions (pure VC units). There are boundaries I have to define. I can either have a 'default' resolution in my core Actor with additional VC Units, or the core Actor is never shown and all resolutions are from separate Actors as VC units. I guess I'll have to play around and think about this for a bit. Thanks for the hint, I'll look into them.
  5. Is it best to ask questions in this thread? Hard to tell for me, however YouTube is just not the place for it For now this is the best place, so here I come: @drjdpowell: In your last video you related to the MVC (or CMV as you called it). As I understand it, an Actor can actually be any combination of Model, View and Controller. In text-based programming languages (like C# for instance) it is common to separate them entirely into separate classes (best case would be zero-coupling). In LabVIEW I think it is okay to separate the Model, but keep the View and Controller close together, as they are bound by design (FP/BD). This applies, unless the View and/or Controller is some external hardware or something alike. What is your recommendation on this? How did you combine them in your actual projects? @everyone: Please feel free to give your thoughts on this too.
  6. RS232 is a very old standard, so even the cheapest devices are quite reliable. For long-term acquisitions however USB is a bad coice. Rather go for on-board or PCI(e). If you really have to go with USB, try one of the NI interfaces. They are well made but quite expensive: http://sine.ni.com/nips/cds/view/p/lang/en/nid/12844 In your case however I doubt any of the USB devices will solve the issue. It sounds to me that the issue is related to the USB connection rather than the device itself. ensegre and hooovahh already mentioned some very likely causes. Such issues might also occur sometimes when connecting another USB device to the same computer. Try to run the application on a computer with on-board RS232. The issue will very likely be solved (if you actually use the on-board RS232 that is )
  7. What exactly do you mean by getting stuck/freeze? Do you have any error message you could post? Also, check if there is any other application or service running that could access the serial port. The MS printing service for example screwed me over a couple of times. Experience might also change depending on your serial device (USB to serial converter, on board controller or PCI(e) cards).
  8. Hi Neil, please use this link: http://download.ni.com/evaluation/labview/ekit/other/downloader/ You'll find all downloader/installer there. The softlib is no longer available. EDIT: Almost forgot this also works with ftp: ftp://ftp.ni.com/evaluation/labview/ekit/other/downloader/
  9. I still think it is justified to wait for SPs and do tests before switching, however the last two releases were focused on fixing bugs and improving stability (2014 + 2015 afaik), with less "big" features like the Actor Framework in 2013. Compared to 2011, 2015 seems to be much more stable at least on my machine (working with a classes is no longer a reason to perform suicide, even with properties ). Being in the club 2011 too, we'll finally move to 2015 by the end of this year (and upgrade to SP1 once it is available). The performance improvement and, as Yair pointed out, the new edit-time features are worth it.
  10. Game over, Game over, Game over, * Smart Computer off * Player 1 has won Thanks for the fun!
  11. The only reason to separate compiled code in the first place is to reduce the file size and prevent incidental file-changes for code under SCC. I think everyone working with the 'separated compiled code' option had to clear the Compiled Object Cache once or twice. So from that point of view there is really no reason to keep compiled code separated, it might acually cause issues where the developer has to clear the object cache to make the VIs work again. That being said, all VIs in my libraries have their compiled code separated... I actually have never given this much thought.
  12. Same for me with LV2011 (32-bit) and LV2015 (64-bit) on W10 (clean install), no VM.
  13. That is cheating! ... But I guess you are right. Hehehe... Found a new toy to trouble our trainees with.
  14. I guess you are right, however the wires are not wired around, the Subtract function is actually flipped horizontally : I'm still trying to figgure out how you did that, flarn2006... Please tell me if it is not possible from within LabVIEW or I die before solving this
  15. Let's care about anyone Alternatively don't care about anyone... but that's no fun
  16. If you don't mind .NET try this: Not sure if there is a build-in solution for that.
  17. True but, if you use a stop watch with a precision of 1 sec, it would (should) show 0 sec and not 1 sec, assuming it has perfect accuracy. The question now is: What did we actually measure? Relatively spoken one second did not pass and also we are no longer at 0 seconds. Meaning that our process to measure the time is not precise enough to give a conclusive answer. Perfect example, this brings us to the question what we actually ask LabVIEW to do for us. So if we request %#.1T we expect it to coerce right? So assuming we have 01.01.1904 23:59:59,999 we expect it to coerce to 02.01.1904 00:00:00,0 Now I want to write information into files, where the file name is build upon the actual date (%<%d-%m-%Y>T), however the entries within the file should be prefixed using the actual time with a precision of %#.1T. In accordance with the coercion, I now expect my file name to be something like '01.01.1904' (we didn't specify any precision, so we expect the highest precision possible, right?). The entry however would be prefixed with 02.01.1904 00:00:00,0! Only a fraction of a second changed, but the entry is (seemingly) in the wrong file. Is this really a problem? I can't tell if such a small 'mistake' is actually a huge problem on the large scale of projects that are done with LabVIEW. To me it would just be an annoyance (I like my files to be as accurate as possible ), so I would most likely write a wrapper to deal with it (which is the reversed role to the solution for coercion ThomasGutzler posted before).
  18. What would happen if you coerce this: The Timestamp would have to coerce up which means the day would be wrong (01.01.1904 23:59:59,999 becomes 02.01.1904 00:00:00,000). Now try that on the 31.12.1904 23:59:59,999... I think this might be part of the reason why the Timestamp is not coerced by design. Time is absolute (or was it relative?)... so yes it is a perversion and we are all vulcanian
  19. Are you by chance searching for this: http://digital.ni.com/public.nsf/allkb/BBB5B94C038267DF8625723E00030559
  20. The 32bit version has the language code attached to it: http://download.ni.com/evaluation/labview/ekit/other/downloader/2010sp1LV-WinEng.exe
  21. Hi Sharon, Please try following url: http://download.ni.com/evaluation/labview/ekit/other/downloader/ You'll find all kind of programs there. The link says evaluation, but you can activate full versions after installation. Greetings, LogMAN
  22. I've seen that many times in LabVIEW 2013, hope that it gets better in the newer version. Anyways, there are a couple of things you could try: Load the project on another computer Clear the compiled object cache and recompile all sources Load the library without the project, disconnect the library from its owner, disconnect all VIs from the library, delete the *.lvlib and rebuild it manually.(Maybe it is not possible to disconnect the library, in which case you can only try to disconnect its members and basically rebuild the entire hierarchy...) The safest way is to revert your codebase, but I assume you don't use SCC right?
  23. Okay, I finally found a solution: A second project had no issues, even though it is basically a copy with a few alterations. After a stroke of genius clearing the compiled object cache for the application builder solved the problem. Now everything is fine again. I hope this helps anyone who stumbles over the same issue.
  24. Hello everyone, I've got a situation with source distributions: I want to export the sources of a project, but some of the VIs should not include their block diagrams. (But they do ) This is what I tried: Create a new Source Distribution and under Source Files add all top-level VIs to Always Included. Next in the Source File Settings select certain folders and check the 'Remove block diagram' option (under Additional Exclusions the checkbox for 'Remove compiled code' must not be checked). When I build the distribution and open one of the VIs, which are marked as to remove the block diagram btw, it still has it! I already found out that this is related to all my VIs having their compiled code separated (to keep source control clean, you know...). So in order to archive what I want, I would have to disable that option, let all VIs recompile, build the distribution, enable it again, and let all VIs recompile again to keep my commits clean... What am I doing wrong here? Does anybody know a cleaner way to do this? I'm still stuck with LV2011 btw Thanks for the support. LogMAN
×
×
  • Create New...

Important Information

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