Jump to content

smithd

Members
  • Content Count

    763
  • Joined

  • Last visited

  • Days Won

    42

Everything posted by smithd

  1. I think if we've learned anything in the past few decades, its that a dedicated attacker can do a lot. I tend to think a password is sufficient -- those people looking for passwords are either: Looking because they have a legitimate reason like they locked themselves out Were never going to pay for it anyway So while I don't know your particular market or customers, I wouldn't generally lose sleep over it. As to the specific question, this may help: http://digital.ni.com/public.nsf/allkb/831F38C46BCBDADE8625793A0054BB19 It sounds like removing diagrams should be
  2. Yeah, so my issue with the 3.5x times is that the visa bytes at port aren't always accurate, especially in my case on linux targets. To give you an example, lets say you have a single master single slave and the master sends 134 bytes. Polling the bytes at port gives you: 0 ms -- 0 bytes 5 -- 20 10 -- 20 15 -- 20 20 -- 40 25 -- 40 30 -- 40 etc... So if 3.5 character times is (in this example) <15 ms, we'd start trying to parse after only getting 20 bytes. I eventually got hold of linux guys in R&D who explained that this is fundamental
  3. ^^ Yeah, I can tell you from personal experience that actually trying to use the 3.5 char of silence is not a great idea. You do need a read timeout and polling, but you should parse the packet as you read it to determine how long its supposed to be, and then check the crc. As mentioned above, the serial software stack you're going through (labview->visa->os) is not conducive to waiting for silence. The packet should be parseable and if you just keep in mind that a modbus packet is limited to a pretty tiny maximum size, there are a lot of checks you can do to eliminate issues and
  4. I still see this in various versions. It usually goes away if you clear cache or restart labview, I think the most extreme I've had to do is create a new project.
  5. It seems to me there is MASSIVE pressure to avoid escalation of these sorts of issues. You say "people don't escalate these things", I say "AE listens to my issue and says they need an encapsulated reproducible case with a bow on top for them to escalate". Thats interesting...to me, a lot of the issues I have with labview are what I'd describe as "transient showstoppers". For example I had a similar issue where right clicking anything would hang labview, and I needed to go to a class property window. The problem eventually went away, and its not a crash. Because of the AE situation, t
  6. Not sure, but have you tried it against another non-NI client? A quick google finds this as a possible free option: http://www.matrikonopc.com/products/opc-desktop-tools/opc-explorer.aspx
  7. Terms like unmaintainable (and, probably more so, the flip side terms of "maintainable", "scalable", etc) bother me because even if they had a meaning, they really mean "code I don't feel like dealing with" (or on the flip side, "this is the style of code I like"). Personally, people who use these terms turn me off to the potentially valid arguments they are making. Before you respond: yes, I understand this is exactly why you want a new name. My main point is that they are not in any way specific, and I don't think this thread can help because you are not specific about how this pa
  8. I've seen the high cpu issue for years, and never use breakpoint manager. Actually the high CPU load issue is kind of a good sign, as its usually after labview has been open for a long time, which means it hasn't crashed yet. Personally I haven't seen anything with 2017 which makes me think its less stable, but I don't use it as regularly as I use 2015. The thing that has me annoyed is that after installing the new driver set max crashes on every single close (in addition to the regular max crashes).
  9. Fair enough... Getting off topic, but at least where I'm at lv most often is competing with python or matlab, so speed isn't a major concern for them . I definitely see the speed gains on RT and the real benefit seems to be memory usage these days.
  10. Yeah I'm on board, I was just throwing out what I thought would be better. I suppose you're right about per function, but per module is handled fairly effectively with conditional symbols by just defining lib_blahblah_dbg. I understand vi_blah_dbg would be more annoying, but then again that depends on how many specific VIs you have to debug at a time. But yeah, I understand neither of those will come to pass in current labview. So let me switch to the argument against your feature: The other concern I'd have more generally is that while you may turn debugging off in your builds, the diffi
  11. Whats the original use case for this? Unless I missed it you start with "I want this" and move on from there. Maybe I'm in the minority but I don't see a use case for this at all. I definitely don't see a infinity use case. If I were in charge of your time, and devoted it so a similar set of features, I'd instead prioritize: Universal debugging checkbox which automatically turns on or off an app-level conditional symbol Per-build conditional symbols
  12. The xnode right click menu (i forget the ini key) lets you see the generated code. I'd suggest just opening the butterworth generated code and copying it directly onto an inline vi diagram, and see if that works or has an issue.
  13. may or may not be sufficient, but since mat files are just hdf5, this library http://h5labview.sourceforge.net has an example for reading and writing the special matlab metadata.
  14. I am using those VIs because I can't update to 2017, so I guess this is the part where I just keep my fork separate.
  15. finding targets is relatively easy: http://zone.ni.com/reference/en-XX/help/373107E-01/nisyscfg/find/ the other part, scripting a target, is officially not possible last time I checked. Theres some internal functions that do it properly (I found them at one point digging through the dialog code), and of course you can edit the project file xml yourself, but nothing great.
  16. its difficult to trust a table like that. to specifically call out one obvious issue...if someone has a copy of your repo, no you cant control access. But the access control doesn't happen at git or hg, it happens at the server. All of those listed servers have reasonable access controls.
  17. I've never tried to lock any git or hg server so I can't help there, but I also absolutely hate that 'feature' of svn, p4, etc so... I find that merge conflicts are rare unless your source is very tightly coupled or monolithic, and of course you can tell if its tightly coupled by how many merge conflicts you have But really, you are the only one one who can determine if the merging will be an issue. If you find yourself very often going to your coworkers and saying 'hey unlock that thingy please!' you will absolutely have a bad time with git. If like me thats happened a few times per
  18. One of these sounds more like NI than the other
  19. I don't necessarily disbelieve you (based on the posts I've seen of yours you do wayyy more instrument control than I do), but thats not how the help describes that switch: http://zone.ni.com/reference/en-XX/help/371361J-01/lvinstio/visa_read/ which indicates that this just changes how the execution system works rather than the logical behavior of the node.
  20. (for context, I just said that my real issue in this case is ni's relationship management. I dont necessarily expect my issue to be fixed but I do want to feel like someone gives a damn. But I decided this wasn't a worthwhile rabbit hole to go down so I removed it.) I guess my view on this is that the AE role is should be to push against the PSEs as the customer advocate even as the PSEs push back and help prioritize quality issues for their R&D groups. I think you're right that AEs are taught to stay in as you put it this vaguely defined set of channels, but whats the point of hir
  21. Not really, an issue is still an issue, even if it isn't actionable. If there is one thing I learned, there is absolutely zero way for me to predict what CARs get fixed and what CARs get shoved on the backburner and ignored for a decade. In this case we're talking about an OS level deadlock, outside of any application code on a software and hardware platform sold directly by national instruments.Regardless of if its reproducible or not, its still an issue to be reported, and there is no reasonable way for it to be my problem just because I'm the only person who hit on the specific combina
  22. I pretty much only make service requests when there is a problem that an AE can't solve, so I think I have a different experience than you For example, did you know that labview RT for pharlap can deadlock at the OS level? Neither did I (well I mean in theory sure, but I'd never seen such a thing). There was no CAR for it, and there is still no CAR, because the AE wouldn't escalate unless they could reproduce it. Through trial and error I'm fairly certain its related to some combination of hyperthreading and IEEE 1588, but its impossible to know for sure because it isn't reliably reproduc
  23. draw.io has a set of process control glyphs which you could pull out, but they are just shapes, no colors or animations. I think its supposed to be used for P&ID diagrams.
  24. apache and MIT have similar benefits, I wouldn't count them out. But yeah, I'm glad I don't have a commercial product to worry about. Has anyone ever looked at the ni-provided legal info in the program files/ni/shared directory? It makes me sad how much effort has to have gone into that.
×
×
  • Create New...

Important Information

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