Jump to content

Mark Yedinak

  • Content Count

  • Joined

  • Last visited

Community Reputation


About Mark Yedinak

  • Rank
    Extremely Active
  • Birthday 03/03/1965

Profile Information

  • Gender
  • Location
    Huntley, IL
  • Interests
    I enjoy racing sailboats on Lake Michigan, canoeing, raising tarantulas, biking and photography.

LabVIEW Information

  • Version
    LabVIEW 7.0
  • Since

Contact Methods

  • Twitter Name

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I am trying to communicate with a Broadcast devices Rf power meter using SNMP and Labview 2014. I am using the simple_snmp_ get vi. I have no errors but not seeing the response I think I should see. Temperature. Need some help


  2. 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.
  3. 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 structu
  4. Count me in. Just bought my ticket. And you can tick the CLA count too.
  5. 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.
  6. 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 le
  7. 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.
  8. 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.
  9. 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.
  10. 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
  11. 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 e
  12. 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 th
  13. 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 programmatic
  14. 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 diff
  15. 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.
  • Create New...

Important Information

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