The Engineering Bear Posted May 16, 2017 Report Share Posted May 16, 2017 (edited) Hey y'all, Wanted to look for some feedback on some code I made for troubleshooting crashes and hangs for medium to large LabVIEW applications. Wanted a way for a user experiencing a crash/hang to have a simple way of narrowing down where the problem is occurring. The VI is named Crash Logger.vi and it only requires the VI itself to use. No type def's, additional VI's, or other necessary parts. The reason for this is so that a user can drop it in multiple parts of their application and have it log the current state and some information on system state to narrow down where a crash/hang is occurring. I've gotten some feedback from friend's regarding making it a global variable that wrote to variables and had a separate VI to do the logging, but this takes away the "ease of use" I am going for for the user. I've included an example application to show how it can be used for a simple state machine. I'd love getting more insight into what I could do better though which is why I'm coming here! Let me know what y'all think! - Bear Crash Logger Project and VI.zip Crash Logger.vi Edited May 25, 2017 by The Engineering Bear Updated Crash Logger and Pictures Quote Link to comment
Manudelavega Posted May 16, 2017 Report Share Posted May 16, 2017 You should probably save your VI for an older version of LabVIEW. Not everybody has LabVIEW 2016. Quote Link to comment
Jimmy Chretien Posted May 18, 2017 Report Share Posted May 18, 2017 Hello Bear, you can click the "Highlight Execution" Light Bulb in the top left corner in the Diagram window and run your VI to observe the dataflow. I think your bug is in the case structure that checks which OS it's running on, your case "Linux, Default" is always used I think, the other cases are greyed out so that's probably where you should double check how to implement that part. Let me know if that doesn't help. Cheers, Jimmy Quote Link to comment
hooovahh Posted May 18, 2017 Report Share Posted May 18, 2017 Yeah for me the conditional disable says that OS is not a defined symbol and so it defaults to the default case which here is Linux. NI has lots of multiplatform code so you might want to look into how they do OS detection. Quote Link to comment
ensegre Posted May 18, 2017 Report Share Posted May 18, 2017 (edited) Also (I'm on linux, desktop), Crash logger.vi is broken because of a missing /<vilib>/nisysconfig/Close.vi and Close (System).vi (This VI needs a driver or toolkit component that is not found. Missing resource file "nisysapi.rc). And, perhaps as a consequence, the "System Session" nodes miss any of the properties they're supposeed to have. Was the code really tested on linux? [maybe on some RT NI-linux, which I miss?] Edited May 18, 2017 by ensegre typo Quote Link to comment
ShaunR Posted May 18, 2017 Report Share Posted May 18, 2017 (edited) I highly recommend you use the native property nodes which are guaranteed to work on all supported platforms. The "Execute" is a last resort and I don't see anything in your code which cannot be obtained with property nodes. Edited May 18, 2017 by ShaunR Quote Link to comment
smithd Posted May 19, 2017 Report Share Posted May 19, 2017 5 hours ago, hooovahh said: Yeah for me the conditional disable says that OS is not a defined symbol and so it defaults to the default case which here is Linux. NI has lots of multiplatform code so you might want to look into how they do OS detection. http://zone.ni.com/reference/en-XX/help/371361J-01/lvhowto/creating_cond_disable_struc/ "The VI must be in a LabVIEW project to access this symbol." Probably best of both worlds is a default case which calls the method shaun suggested and otherwise its compiled in. 1 Quote Link to comment
ShaunR Posted May 19, 2017 Report Share Posted May 19, 2017 10 hours ago, smithd said: http://zone.ni.com/reference/en-XX/help/371361J-01/lvhowto/creating_cond_disable_struc/ "The VI must be in a LabVIEW project to access this symbol." Probably best of both worlds is a default case which calls the method shaun suggested and otherwise its compiled in. This is why I prefer the "TARGET_TYPE" which doesn't have this limitation. Quote Link to comment
The Engineering Bear Posted May 25, 2017 Author Report Share Posted May 25, 2017 Thank's y'all for the feedback! I realized that I had been uploading a non working version, but that just gave me some time after NI Week to work in some of your suggestions! The one I'm most curious about is switching from OS to Target_Type. Using Target_Type definitely has more options, but then how would you specify things like file path so that the user knows where to find it/make sure they don't put it some where they aren't supposed to? -Bear Quote Link to comment
ensegre Posted May 25, 2017 Report Share Posted May 25, 2017 18 minutes ago, The Engineering Bear said: how would you specify things like file path so that the user knows where to find it/make sure they don't put it some where they aren't supposed to? This way perhaps? (or maybe this one since now we're all obsoleting out) Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.