Jump to content

Yair

Members
  • Content Count

    2,842
  • Joined

  • Last visited

  • Days Won

    41

Everything posted by Yair

  1. Some people wait for the SP releases. It's certainly less likely to have new bugs, as they rarely have new features, but .0 releases are not exactly hotbeds of crashes automatically. I know I used 7.0 for years and was perfectly happy with it. I suppose depends on how sensitive you are to perceived potential bugs, but I don't have any actual data about the stability of .0 and .1 releases. I actually generally try to avoid upgrading if possible, because it's a hassle and can make project management a pain.
  2. If you're upgrading, I would consider 2015 seriously. The changes to the make space feature and context menu plugins are worth it.
  3. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-Asynchronous-Call-By-Reference-with-Strict-Static-VI/idi-p/1662372
  4. I have code (which I can't share) for batch processing VIs which call the function from a DLL and do a bunch of operations on each. I don't do the specific changes you want, but the concept is the same. Some relevant points: As Jack mentioned, this can be problematic, at least if you also have to start adding the code which you mention in the end of your original reply. I didn't, so this code can only be run after generating the wrappers. Keep in mind that you might want some VIs which don't get this treatment. To do the wrapping, you should create a disable structure, select everything on the diagram (my suggestion - exclude all ControlTerminals) and then call the EncloseSelection method on the VI's diagram (give the created structure as the EnclosureType) and delete the original structure. You can then probably use the properties to set the conditions.
  5. The SubPanel class also has a private method called Insert Remote VI which takes an address, port and VI name and presumably uses VI server, but it has no documentation and I didn't even notice it until now, so I have no idea if it works, and it certainly won't be supported even if it does.
  6. One good reason to separate is that recompiles still happen in released code (change platform/bitness/version etc.) and if you don't separate, LV will show your VIs as modified unless the installer resaved them after install (which VIPM is supposed to do if it's configured to, but didn't always work). There are also cases where VIs occasionally decide they need to recompile for no apparent reason (VIs which have ActiveX calls are particularly bad at this - they decide they have a different component from the one they had before).
  7. Some potential options: Open a reference to the remote app and to the VI and insert that into a subpanel. I'm pretty sure this won't work, but it's certainly worth a try. Use remote front panels. Haven't done that in a very long time either. Use a copy of the VI and bind the controls and indicators to shared variables. Use the Windows API parenting functions mentioned here, like SetParent. They're fairly easy to use and there are even VIs which use them online (although you should note you can have one copy of the window at a time and there are potential weird artifacts which can happen). Implement a VNC server. I'm not sure how much work that is to implement. Maybe that's what the ancient LabVNC does.
  8. For the most part, I'm managing fine with Windows 10 (after setting a bunch of preferences I had which it decided to reset). Certain things about it are nice, like the window management. The two things which are still annoying me: You can't pin arbitrary items to the start menu. If you want it there, you have to copy it to the correct folder and it appears in the apps list, from which you can pin it. Windows Update decides on its own when it will install updates and restart your computer. If you ask it nicely, it will allow you to set when the time when it will restart on your own, but it *will* install and restart. Apparently this can be overridden with a group policy, which I have now set, so I will see if that works.
  9. You certainly shouldn't need XNodes for PID. As flarn says, just use a subVI. I would also say that unless your goal is learn about PID by implementing the algorithm, you should just use NI's PID VIs and focus your time on other things. I'm not sure what you need to get the PID VIs (I think in recent versions they're freely available, but if you're a student, you probably have access to them even if they're not), but you can search for that. If you still want to create it yourself, you should start by making sure you understand both the algorithm and LabVIEW well enough. I have no particular content to recommend for learning LV, but you can start here - http://labviewwiki.org/LabVIEW_tutorial
  10. I would suggest you not use LV for this. There are dedicated programs for setting up complex installers and you would probably be better off with one of those. In LV, the only real customization is the ability to specify an EXE to call after installation. I have no experience with such programs, but there have been some threads discussing them over the years (I would suggest looking under the relevant category, or searching for "InnoSetup", which is the only name that immediately comes to mind). It also seems to me that you have some confusion about how projects work. They are not some magical file system which takes care of things automatically. They are simply an organizational tool which LV uses. Every item in the project points to a specific file on disk. Virtual folders are simply a tool for grouping items in a way which would be more relevant in that context.
  11. I wonder if this can work: Open the typedef. Save the enum control somewhere. Replace the enum with a numeric. Apply the changes. Do your disconnecting. Replace the numeric with the enum you saved. Apply the changes. A quick test indicates that replacing a an enum with a constant and a constant with an enum preserves the value, but I don't know if this applies when you do it with a typedef and I don't know if it will help with this specific issue even if it does work on typedefs. My guess would be no, because whatever's resetting the value will probably still happen at some point in this process, but that's just a guess.
  12. I haven't worked through all the implications, but I wouldn't be surprised if you're right and this isn't strictly necessary (because the DVR doesn't need an actual object allocated) and with enough work, NI could resolve this in the same way it resolved static recursion. My guess is that if this is the case, this is simply an inheritance from static type recursion, where LV does need to allocate a value statically, since you can't have a null object.
  13. This was actually there back in Lotus123 and is apparently by design, as it allowed the program to calculate leap years by using a much simpler algorithm at the cost of being wrong for 1900 and 2100. Probably a minor price to pay for a program designed in the early to mid 80's.
  14. If you really don't want to start modifying the code too much (and based on your description I'm guessing the loop is probably large), another option which is more compact is a feedback node:
  15. I'm pretty sure all the functionality should work, but I don't remember testing specifically. You can look at the documentation for each method or make a small test app. Some potential caveats: LV strips the BD of all VIs that go into an EXE unless you explicitly tell it not to. Without a BD there's nothing to capture. LV strips the FP of most VIs which go into an EXE. For both, this isn't relevant if you're looking at external VIs. At some point, LV lost the ability to read an image from the clipboard in an EXE. The method just doesn't work. I don't think this affects writing an image to the clipboard, but it might.
  16. It is, and it's two sides of the same coin - the static link is simple to understand - LVF has an LVFR, which has an LVF, and so on. There is an issue with resolving the type, because you have to keep adding more layers infinitely. The dynamic version works because this doesn't actually need to happen - when you stuff the LVF DVR into LVFR, the actual object inside the DVR has its own LVFR which doesn't point to any other object (its data type is LVO and the DVR is empty), so the recursion stops at that point.
  17. LVFileRefs should have a DVR to a LabVIEW Object (not LVFile). At run-time, you populate this with a DVR of a LVFile. You create an accessor which reads the DVR and casts it down to an LVFile DVR for using it (you might need to do the casting inside the IPE structure).
  18. Again, the type should be of a parent class. You only cast the object down to the correct class at run-time. This does work. I don't remember trying specifically with a DVR, but I believe that should work too.
  19. Is this comment and the ones following it more to your liking? https://decibel.ni.com/content/message/106904#106904
  20. I haven't read the rest of the thread closely, but in case this can help you - you can do this, but the data type needs to be that of a parent class (like LV Object). You can then use the accessor which reads the DVR to cast it down to LVFile.
  21. I haven't looked at the code, but there are also other ways of doing this. If you think about an FGV, it's essentially just a way of performing different actions on the same piece of data. Your code creates a wrapper to turn the actions into VIs. If you're doing that, you can also just pull out the data and get rid of the internal FGV entirely. For example, the shared data could be a cluster (or an object) in a DVR. Each action simply takes the DVR and operates on the data, so the "increment num" action could look like this: It starts with a call to the GET DVR VI (inlined into the caller here for simplification) and then does the action. This allows you to get rid of the enum and the FGV VI itself and the need to match the API correctly. It might make debugging more difficult, because you no longer have a single VI you can go and probe to see what's happening.
  22. Yes. Since it looks like this is directly copied from LV, it's no surprise that you can create something very similar in LV and it's quite likely that their image started as code in LV. My point was simply that it looks like they didn't use LV itself, but rather created their own visuals, where they did whatever they wanted to, because their only constraint is for the visual to look good on screen for a second. Do you really not see all the differences which make it clear this is not LV (things like case dropdowns on the left side, tunnels which are too big, diagonal wires and several others)?
  23. No. Again, it looks like they took some LV code and then created a completely custom image which looks similar, but isn't actually LV. I agree that the signal split and merge do look exactly the same, but there are many things which are clearly not LV, the IDE not being the least. The "Z transform VI" actually appears to be their version of Build Waveform.
  24. Sounds interesting, but I don't think the functionality is clear enough (things like "Is this for live data? Historical data? What does the web app look like? What does the phone app look like?", etc.). I would suggest creating some videos and examples and maybe also adding a public test account which people can connect to (at least for reading, if you don't want someone flooding your server with useless data) to see how the system works.
  25. The OS there also seems fake (although I'm not familiar with all of the Linux desktops, so it could be one of those) and it's very blurry, but I think the title of the windows is DataFlow 5.3.4 (the name is almost entirely from context and the digits could be pretty much anything). I wouldn't be surprised if you something that looked very similar to Merge Signals. As far as I can tell, that graphic is directly inspired by LV.
×
×
  • Create New...

Important Information

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