hooovahh

Right but, if I asked you to round 3517564740 (what I think is June 19 at 13:19 for you) to the nearest 86400 (24 hours) you would say the value is 3517603200, which ends up being the next day. But I could see how this could cause confusion.

What about it? You state the day is wrong, which is true but rounding up to the nearest second could mean the second is wrong, it doesn't invalidate the fact that you only rounded up a fraction of a second. Yes time is absolute and relative I guess. So if we think of it as seconds passed from some date GMT, rounding up a fraction of a second doesn't mean anything more than just rounding up that fraction of decimal. Also your date example of rounding to another day doesn't matter to the other 23 time zones that would still be in the same day. None of this explains why NI chose to do what they did, but in opinion this isn't much of a reason to treat timestamps different.

Rounding time up? Like traveling into the future? That's just crazy! Rounding down is fine, it's like going into the past, you know the past exists you already were there. But how can you round up, the world might end in those milliseconds you rounded up to, now won't you have egg on your face when you look at your data after the world has ended, and your timestamp shows data was taken after the world ended. But seriously though, other than philosophical reasons, I don't know why we couldn't round up when appropriate.

I don't have IMAQ installed but I think those settings are exposed using various property nodes. I also remember those settings in MAX and saving them in MAX retained the values. So in the past I've just set it up in MAX and saved it, and never needed to change it for the application.

Launch the example finder by going to Help >> Find Examples and search for Simple Serial. There are also several examples on the NI forums and even here. https://lavag.org/files/file/172-hyper-terminal/

It is a handy feature to have. Especially for UI's that you have lots of panes and scaling happening. There are times that going too small just breaks things, so you make it as small as you can, then set the size to that to make sure the user doesn't make the UI unusable. Like I said there is a property for each pane as well but this is harder to get at because you need to drop down property nodes to read, they aren't viewable in the VI Properties. And then weird things can happen if you try going smaller where a pane can't get small but the window can so I almost never use this feature.

That's an interesting approach, with several pros and cons over the typical poll the timeout case and check method. A few comments, you aren't closing lots of various references, and I figure you probably just threw this together. You have a VI reference, notifier, and user event for each trigger that aren't being closed, and you aren't unregistering for the user events. Some of these take care of themselves when the VI stops but I don't think they all do. Also I'm not sure you are aware of this or not, but you can create an array of user events, and register for all of them at once as long as the data type of the user events are the same. This might help make things scale easier because you could be making timing sources in a for loop, and to add another source you just need to run the for loop another iteration. Overall I like the concept. I keep going back and forth, but I do not think I have a need for adding things to the end, and front. If I go off and do some things, and I want to go to Idle periodically to see if there is new events to handle (like a trigger) my first thought is I would want to add Idle states to the front, then add the states added in the event structure at the end, unless it is a critical thing like shutdown. But this isn't true because when I add Idle cases is is probably going to be in a Macro all at once, so it doesn't matter if it is at the end or front. And as for going to Idle periodically, I wouldn't want to go there until I was done doing what I'm doing anyway, and then the event structure will act like a queue and my events will be waiting for me when I'm done doing what I'm doing. In the past I've seen where the states were always added to the end, except for an exit which was added to the front. But again with this design you're not usually going to go check to see if you should exit, until you're done going to your states, so it didn't really matter. Oh and I've used the DAQmx events. Just like all state machines where you have work, and UI stuff in one loop you need to be mindful that things should happen quickly, so the UI appears responsive, and you don't delay the work going on. Like you probably wouldn't want logging in that same loop because an event is generated for taking DAQ, then you take the DAQ log it, do limit check, database, or whatever, and this whole time your UI is unresponsive.

Certainly posting the VI might help. Short of that I've seen this issue when using this function a couple times, all of which were expected if I had stopped to think about it. The first is maybe your front panel has a minimum size set, and the decoration is less than that minimum. In this case you won't be allowed to make the window smaller, so it throws an error. I've also seen it do odd things when there are splitters and multiple panes on a UI, where it will try to scale the window to the largest decoration, but that decoration is only on one pane. I've also seen where there is a minimum pane size, and again the decoration is too small. I'm sure there are other reasons this VI can throw an error. Because of these types of issues I don't use this function too often any more. I also heard someone mention this function does nothing, and returns no error on the new cRIOs running embedded linux, with a monitor plugged in, but I didn't get a chance to debug it.

I'm interested less in making MDI applications, and more in knowing that NI has provided the tools, to make any application my imagination can come up with. Put another way, I'd like to have the ability to take any existing program, on any platform, and be able to recreate it's UX. I want users to use my program and not know it was written with LabVIEW. Exposing the HWND, or providing wrappers to similar cross functional APIs is one step towards that. And to be fair the window management properties in VI Server is a decent step in the right direction.

I don't completely agree with your Always statement. If JKI didn't want us to be able to enqueue at the end then they shouldn't have included that feature. They obviously saw a need, or their users saw the need for it. Oh and jcarmody said without launching an actor.

Oh that's a great idea, and a case I haven't really thought of because I generally have had another actor doing the actual work, and the state machine is just the UI, but there are plenty of times the quick and dirty is to have it be in one state machine.

For me I don't ever add an "Idle" to the Add States. It just goes there after it is done doing what I asked it to do. So you go to the Macro Initialization. It does the states you tell it to, and then when it's done it goes to Idle, where you may have a timeout. In the timeout it might go to another Macro to do stuff, and after all of the states I add are done it goes back to Idle. It does this because when there are no more states to pull out, it passes out an empty string, so you should go to the "" case. Drop down the JKI template and run it. If you press the OK button or close the window it should react to your request by going to the Macro Exit case. It does this because it was in the idle case polling the event structure. You could add you own "Idle" to the states but I have never had a need for that, it will just go there when I'm done. And going to the idle case doesn't need to wipe away your string queue. If you go to the "Idle" case then perform an event with a button press, you can still use the Add States to add more. But in my software, since I never add and "Idle" case, to the states to go to, I will only go to the Idle case if all state have been processed.

Interesting read, and LabVIEW definitely falls into this category, and not just with threads. Ever allocate memory for a variable in LabVIEW? Maybe you initialized an array and used replace instead of build, but this is not the same kind of memory allocation other languages think about. What about parallel tasks? Memory cleanup? Obviously being a higher level language many things are hidden away, and with a really advanced compiler even more things are hidden from the developer. I was talking to a friend yesterday and he made the statement about how easy software programming is, compared to previous decades. And while I agree I think the challenge has shifted. You no longer need to worry about the things that are abstracted away (until you do), but you do need to worry about much larger systems, with a much smaller team. We need to have more architect skills, and be thinking about how the pieces plumb together, and worry less about the low level, and assume they are water tight. When they aren't, we struggle.

Here's some information on the .net functions called. https://msdn.microsoft.com/en-us/library/bb299773(v=vs.110).aspx https://msdn.microsoft.com/en-us/library/system.directoryservices.accountmanagement.principalcontext.principalcontext(v=vs.110).aspx https://msdn.microsoft.com/en-us/library/system.directoryservices.accountmanagement.principalcontext(v=vs.110).aspx

Unofficially they do, but yeah you may want to post over on the NI forums, for higher visibility.

I'm guessing there is a tiny border around your string control. Is it possible that this string is in a cluster? If so you could try to minimize this by using the 1 pixel border cluster. https://lavag.org/topic/5013-compacter-cluster-arrays-tables-with-controls/#entry28056 If that is just a string control I'm not sure why the label doesn't position itself right. Actually I just tried it on another XControl and it is the same. I'd say this is a bug and needs NI's attention so they can make a CAR.

Oh also fun with parent children relationships. http://screencast.com/t/LjlkYzTWKr8J https://www.youtube.com/watch?v=-i3iaWm_Jiw http://screencast.com/t/P9SJ1anR https://www.youtube.com/watch?v=bqNVbSn7nKg http://forums.ni.com/t5/LabVIEW/How-to-run-an-exe-as-a-window-inside-a-VI/m-p/3113729#M893102 https://lavag.org/topic/17046-multi-panel-interface/

So today I found another method that in my opinion should be made public. Obviously NI has more information than us, and maybe they have a good reason to not make them public, like they crash LabVIEW if you do XYZ. But here is a couple I've found and thought were odd that they were still private. These are functions that from what I see work just fine, and have little danger to a developer using it. Please add others you find. Class:VI Property: FP.Native Window This returns the HWnd in Windows to the front panel window, which can be used for low level window manipulation. Many functions for window manipulation are in VI Server but not all of them which is why on occasion the HWnd is needed. Class: Ring Property: Flavor This returns the type of Ring a reference is. Text Ring, Picture Ring, or Text and Picture. Class: VI Method: Synch In All Contexts I'm not sure this actually works, but it looks like it should sync a VI to all contexts. Maybe this isn't needed because a Save Instrument also syncs but some times you may not want to save the VI. Class: Control Property: Grouped / Group Member Refs This returns if a control is part of a group and the other references in the group

On modern Windows the folder is something like C:\ProgramData\National Instruments\MAX\Data Not sure where ProgramData maps in XP I think it was something like C:\Documents and Settings\User\AppData\Roaming\National Instruments\MAX\Data but you'll have to look around to see. I think DAQmx settings are saved in config3.mxd, I don't remember what file the traditional DAQ is saved in but I'd bet it is in that same directory. If this doesn't work is it possible to deploy that image to a temporary PC or a virtual PC, then do a MAX export, and then import it back on the new PC? EDIT: Oh here is some more information. http://digital.ni.com/public.nsf/allkb/DAD981AFEF149B458625778100775987

I don't have those versions installed anymore but you may find more help over on the Version Conversion subforum. http://forums.ni.com/t5/Version-Conversion/bd-p/VersionConversion

Yeah use the Elapsed Timer express VI and set it to the time you want. The output is "Time Has Elapsed" Then you can use that in a case structure and only do the work when that time is up.

So no one has ever told me this, but from what I've seen child references won't be closed using a close reference, if a parent is forcing them to stay open. Make a new VI, drop down a control of any kind. Right click and create a static reference to that control. Use the Close Reference on that reference, then use a property node to read the label text of the control, passing the error out of the Close Reference into the error in of the property node. Now run the VI. The label is still returned, and the reference is still valid even through you asked to close it. This is because even though you asked to close the reference, it needed to be open because the VI that uses it is still in memory. Reading the detailed help on the close reference function has more information on this. This might also be compounded by the fact that I think this is an example of a "This" reference. So closing the control reference in my mind does nothing, unless you explicitly opened the reference using the Open VI Object Reference. So if you opened a reference to a VI, then used a property node to return the control references on the front panel. Then it is my understanding that you don't need to close the control references, when you are done. All you need to do is ensure the VI reference you opened gets closed. As a fun test I'll usually write a simple VI that does my work and closes the things I think it needs to close, then use the Run Continuous button and look at the task manager and see if memory increases. This is the only time I find myself using this button.

Well I know nothing about EtherCAT but I have some links that you've probably already found. http://www.ni.com/white-paper/7299/en/ http://www.ni.com/white-paper/14140/en/ 80 views isn't that much, there are many lurkers. And there are people like me that opened it up to see if it was something I could help with, then I closed it because I couldn't. Oh an there are some that just read every post so that it is easier to find the unread posts.

What IDs are you reading, what IDs are you missing? You didn't post any code, but even if you did I might recommend contacting Stratom. They likely have an example that is made to just read all data and display it. Is is possible the device is setup to only read standard CAN messages and is missing extended ones?

Sure but a crosspost helps give some context to those unfamiliar with the history of the issue.