Jump to content

Mark Yedinak

Members
  • Posts

    421
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Mark Yedinak

  1. I took a look at JSON and I definitely like it better than XML. The problem in this particular case is that I will have binary data as part of the data set and JSON doesn't look like it supports that very well. I will probably just define the data format using a basic C style structure and decode/encode it in LabVIEW.
  2. Is the variant data type well enough defined that a specification can be given to programmer's using another language that they could decode/encode variant data? I am working on a messaging interface that will pass messgaes between LabVIEW, Python and possibly C/C++. Obviously within LabVIEW variants are a very convenient way to pass generic data around at the lower levels of a messaging API. However, the format of the data when flattened to string to pass over TCP connectons is rather daunting. Is my best option to change my lower level code to use a more conventional and defined data structure (basic a simple stream of bytes) and then parse that ino meaningful constructs in LabVIEW? That is, where I currently have variants should I replace them with a string and then at the appropriate places decode that into a cluster. Taking this approach would allow me to define C style structures which can be easily read/transmitted in other languages.
  3. Count me in. Just bought my ticket. And you can tick the CLA count too.
  4. No, The data collection loop is running at a whopping 1 sample per second. The display and logging tasks are driven by the collection tasks. That is what is so baffling about this leak. This application is running at a very slow pace and to see the increase in handles and memory over a short period of time is quite surprising. I will be digging into this more later. I don't think I'll get a chance to work on it today though. Thanks to all for the suggestions.
  5. OK, I haven't broken the application down into the component parts yets but did rebuild it on my local machine (this application actually runs at a client site) and monitored it overnight. The memory is slowing increasing and the stats from perfmon shows that the handle count is extremely high. The handle count was well over 7000000 after about 6.5 hours of running. The memory size was 5 times greater than when the application started. It is colecting the data from a remote site using HTTP once per second. It then logs that same data into a DB. Both the HTTP connection and DB connection are left open. Does the extreme handle count provide any clues where to look. I will break it into three separate applications for test purposes but thought the handle count may point to a specific area.
  6. And no, no DLL's that I know of. If the password protected stuuf is calling something though I would have no way of knowing.
  7. The beauty of user events is that you effectively get a one to many queue. Notifiers are one to many but can only contain the lastest data. User events will queue up th eevents like a queue but the sender only needs to generate a single event to broadcast it to many parts of the application. Queues on the other hand are many to one. To get a broadcast message either the lower level code has to know everyone who will get the message or you implement some middle man task to receive the message and post it to the queues for everything (publish and subscribe) interested in getting it.
  8. This would probably work. I think I would try this with the HTTP and DB tasks. I suspect it is one of those causing the issue and not the UI task. My first inclination is the DB task but there isn't much there on my end and the tollkit VIs are password protected so it is hard to say what they are doing under the hood.
  9. Yes, I do realize it is very difficult to give advice without the code. Anything in particular to look at with the dynamic registration? I have two sets of user events that the tasks register. One is what I call application events that are general events like start, stop, exit, etc. The other is application specific events which as the name appies is events specific to this application. I use an AE for each set of the events and separate VIs to actually post the specific events. The events only get registered once in each of the tasks. Your idea abouth separating the tasks is interesting but I would need to have some different method of passing the messages between them if they were separate applications. the events would not pass application boundaries. Without the messaging only the data collection task would actually do anything. The other two are acting on messages out of the collection task.
  10. I am running into an issue with a memory leak. Due to NDA I cannot post code. The issue is have is that the deployed exe has a memory leak yet I do not see it when running in the IDE. The code is fairly basic and consists of three tasks. The first task is a basic UI event task and it does updates two strip charts during execution. The second task is a data collection task that retrieves data from a device using HTTP. The third task is a data logging task that writes the data to a database. Messages are passed between the tasks using dynamic events. Each task is basically a while loop with an event structure. Tasks two and three are subVIs on the top level block diagram. I have scoured the code for any unitialized shift registers or run away arrays. Tasks two and three both open their connections (HTTP and DB) once and use the same connection throughout the execution. Error processing will open a new connection is there is an error but it will cleanup the old connection. Also, I have not recorded any errors so they application should be using the original connections it opened. The DB stuff (using the database toolkit) is executing stored procedures. It does free the resources for each transaction. I have run the execution trace tool (not on the built exe), profiler and VI analyzer and nothing is jumping out. Any ideas on how to isolate what is causing the memory leak? As I stated the leak only exists in the built exe. Running in the IDE shows memory usage to be very stable. I am running out of places to look. Any thoughts or ideas would be appreciated. (Sorry about the lack of code, but I'm not at liberity to post it.)
  11. I will have to look at the application instance specifics. To answer your questions though, we are using a custom process model, we are deploying this as an exe and we do ensure that we keep the development environment/run-time engine settings in synch. When we deploy TestStand is set for the run-time enviroment. We have seen cases where it would work in the development environment but not the deployment. In the past we had asked NI about sharing a queue from the GUI to TestStand. We were told it was not possible. This was why we opted for a network based solution. We did find a solution to this issue. Our messaging libraries had been using a single client queue to post messages to our message server (network based). The problem with this was that TestStand and LabVIEW could not share that queue. Our message class orignally only provided for a single quueue reference. Our solution was to allow it to manage multiple queue references. This all happens internally to the class. As a result we had to create an initialize method for our messaging class which would provide a unique "client ID" for it's messaging. Calls to the post message method simply needed to use the "client ID" when posting messages. The message class manages the various client queues and everythign is working now. Everything is neatly bundled up and if our messaging class is used in a single application the client ID is not necessary, therefore nothing special has to be done to use the messaging class.
  12. We have confirmed with NI that the memory space is not shared between the LabVIEW GUI (application which starts and controls the TS sequence) and the TS sequence. The queues we are using pass the data over the network so that is not the issue. We can pass data. The issue that we have is our generic messaging system is using a functional global to hold the queue reference and unfortunately this FG does get shared by the GUI and the TS side. However, neither side can use the other's queue reference. We need a very generic method to obtain a unique ID of some sort that can be derived programmatically. This value would need to be consistent within the confines of the GUI or the TS side of things yet be different from each other. Our current approach using the application name and process ID does not work since this is the same for both instances. In addition, I don't want this method to assume the presence of TS. It has to be TS agnostic. Some thoughts I had would be something along the lines of a thread ID. Though I am not sure this would work since I can't find a way to get that value and I believe that NI's scheduler can place the execution on different threads which would not guarantee uniqueness across multiple calls. This solution cannot use a wired in value since these message objects are several levels deep in the library code as well as being used within different libraries. We have already tried the owning application reference thinking this may be unique but it isn't.
  13. I have run into a bit of a problem and wonder if anyone has solved this or knows of a solution that will work. We have an extensive library of reusable LabVIEW classes that we are utilizing both or automation framework GUI and TS sequences. A part of these libraries is a generic application messaging systems that is based on a networked based queue. Our messaging classes are self contained and designed to not require any external input. They use internal data for references to the queues. The problem we have encountered is that in our application the GUI and the TS sequence actually share different application space and cannot share a reference to a queue. We need a method to programatically determine which memory space we are in. We would use this information to do a look-up for the correct queue reference. We do provide an initialize method for our messaging class which will create the queue and store the reference. We need a way to get a unique identifier based on the memory space it is running in. This method needs to be generic and not assume we are running in a TS environment. The process ID and application name will not work since both the GUI and TS sequence will share this. Any ideas on a workable solution?
  14. Well, the solution I posted earlier worked fine when adding a single line of text but fell apart if data was added in chunks. Here is the latest and greatest method for achieving what I wanted.
  15. I will have to look at that. If it uses a standard library in the LabVIEW distribution I can modify the code to use that. The problem with an llb file is that it uses absolute paths which can cause problems when using source code control. I would like to avoid that issue hence my desire to break the VIs out and add them to a lvlib file instead.
  16. Does anyone know the password for the GetSocketInfo VI in the above library? I would like to make my own library with several other functions. I would like to use the new lvlib format instead of the llb format. However, the one VI is password protected and therefore I cannot add it in any other library.
  17. Thanks Ravi, but your simplified VI does not accomplish what I wanted. As I have stated I want the auto-scroll to keep the scroll bar position at the end of the display as new data comes in. HOWEVER, if the user moves the scroll position up I want to disable the auto scrolling until the user moves the scroll bar pointer back to the end position. And this has to work with data that does not have actual lines. The data my be what is effectively extremely long strings of arbitrary and possibly binary data with no carriage returns or line feeds. The solution I posted above mostly accomplishes this. In the actual application I will be using it I have found a case where I am unable to re-enable the auto-scrolling when I move the pointer back to the bottom.
  18. Thanks to all who responded. I found the solution in the thread Darrin posted above. I wish this functionality was built into LabVIEW but in the meantime I have a workable solution. Here is the test VI I was playing with to test it out. Auto Scrolling String Indicator.vi
  19. Thanks for the suggestions everyone. Unfortunately simply counting lines is not a solution that will work. In my case I have long strings with no new lines or carriages returns. In addition, if the text wraps in the string indicators what it considers to be the number of lines does not necessary reflect the true number of lines as determined by some end of line character. For example, this paragraph will only have a single end of line character yet within the string indicator it will be seen as multiple lines because of word wrap. If the size of the indicator changes the number of lines also changes. This is a very dynamic number (and somewhat random) in terms of the scroll position. Since I will be updating this display frequently I would like to avoid having to pass it through some line counter VI. I posted an idea in the LabVIEW Idea Exchange which asked for an auto scroll property built in for scrollable items. Hopefully this would include this functionality as well if they chose to implement it. If you have any other suggestions I am open to hearing them. Thanks.
  20. I'm trying to create an intelligent string display that supports a scroll bar and auto scrolling. The auto scroll is easy. However, what I would like to be able to do is continue to auto scroll as long as the scroll bar is at the bottom. If the user moves the scroll position to something other than the bottom the automatic scrolling will be disabled. Again, this is easy to accomplish. The challenge though is to know when the user has position the scroll bar at the end again so auto scrolling can continue. My string indicator will allow for a fairly large string (10s of thousands of characters) and can contain binary data including the NULL character. The scroll position property is the line number that will appear in the top of the display. However, there doesn't seem to be any way of determining how many lines there are or how many lines the indicator thinks it has. It still has a concept of lines even if there are no actual carriage returns or line feeds in the data. Has anyone solved this issue? Does anyone have any ideas that may help. I have been struggling with a good way to determine when the user actually moves the scroll bar to the end position. And just to keep this challenging the indicator will be getting automatically updated with new data. I want to allow the user to move the scroll bar and not have the display jump to the bottom again as new data is added. I do however want them to be able to move the scroll bar to the bottom and effectively turn the auto scrolling on again.
  21. I've also experienced TCP/IP issues with Windows 7. We haven't fully isolated the issue but an application we have that sends quite a bit of data over TCP/IP in Win7 experiences lots of problems but runs like a charm on XP. I also did some traces of the communications and the traffic pattern in the Win7 cases was very strange from a networking perspective, including unexpected TCP-RSTs.
  22. Does some other application have the port open? You can get this error if the port is in use.
  23. Just bought my ticket. I'll need a beer at the block diagram party and the BBQ. My presentation is during the last slot on Tuesday.
  24. Sorry it hear it did not work out better for you but at least you understand the grade now. I hope you decide to try again. One thing did jump out at me in your last post. You mentioned not being able to use another library to implement your solution but it is important to understand that the CLA exam is not looking for your complete code, but for the architecture to give someone else to implement. You need to design the framework for the application, not the application itself. Therefore you do not need to have the messaging library in order to complete the exam. You could easily have documented that the application requires the messaging library (perhaps even specifying a specific one) and describe how the messaging works. You are not required to actually implement it. This can save considerable time on the exam. Good luck should you try again.
×
×
  • Create New...

Important Information

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