GregFreeman

I was being facetious

Part one of that statement is purely separating the job queue from the incoming queue, but I understand your concern. Part two I noticed after I posted *facepalm* I'm back looking for the silver bullet, has anyone found it yet?

After reviewing this, I think it gets me pretty close to what I want but not exactly. This is because there are other "Tag" structures/classes that need to be written to a file, also. The DoSomething method is flattening these particular classes to be written to a binary file. I am almost feeling that I need interfaces, so I can have the "FileWritable" interface, with a method FlattenToFileData() which would allow me to separate the inheritance heirarchies but still enforce this method. For the time being, I have broken out the inheritance heirarchies as you suggested (Tag separate from data), and in each one have put a must override, FlattenToFileData() method. It's a bit redundant but will do what I want.

Thanks, I'll digest that in a minute. The reason for this behavior is because they are logging to a binary file, and we are trying to match that file in our new system so existing parsers will work. Each record defines some common data for the test, but the data in the record itself can only be one type (FAT, GAG, etc). That is the use of the union in this case. I felt that lends itself to injecting the proper data type for a test, into a single member variable at runtime depending on the test type, and scrapping the union.

Bit of a brain fart I think... I believe you're right James. I should make these a child class of "C" or SpectrumData_Tag. Just queue up either Fat, Fat2 etc and all the data I edited out would be in the parent class (SpectrumData_Tag), because it pertains to all children types. I think the problem came from forcing the existing structure layout into my OO architecture. But, the problem then becomes, they could queue up SpectrumData_Tag itself, which is relatively meaningless; it needs to have the associated data from Fat, Fat2, GAG, etc. I suppose this isn't that big a deal though.

Their own overriden method will be called inside Cs method, but they do not directly use C's method. This may clarify what I'm trying to do. I have an existing structure in C/C++ typedef struct {//edited some stuff out to be more concise for this post union { struct { fat_data_record_TAG id[TSNCHN]; } FAT; struct { fat_data2_record_TAG id[TSNCHN]; } FAT2; struct { gag_record_TAG gi; } GAG; struct { int RecordNumber; int EventCode; int CurrentLoadCondition; int CurrentLoad; int GoingToLoad; char Desc[TSLDES+1]; static_data_record_TAG sd[TSNCHN]; } STA; struct { int RecordNumber; int EventCode; int CurrentLoadCondition; int CurrentLoad; int GoingToLoad; char Desc[TSLDES+1]; char ItemCode[TSNCHN][TSLITM+1]; } RDB; } Data;} SpectrumData_TAG; Unions don't exist in LabVIEW obviously, so I was going to replace the union with a single, DataRecord member, the type of which would be injected. Now, I have classes FAT, FAT2, GAG, STA and RDB, one of which would be injected at run time. The problem is I don't want FAT, FAT2, GAG, STA, or RDB to be sent to my logger alone, they need to be inside the SpectrumData_TAG class. However, because SpectrumData_TAG along with FAT, FAT2, GAG, STA and RDB are all DataRecords, the method to "send new record" will accept them all...there is no protection from a FAT, FAT2 etc from being sent. So, I assumed by breaking up the inheritance heirarchy, I could protect from this. But, then I lose the fact that FAT, FAT2, GAG, STA, and RDB all need to have a method which is defined in the DataRecord base class. So I end up duplicating that. Clear as mud?

This will be running on a pxi chassis which I think runs Pharlap or VxWorks, but the previous code was running on something that was modern at the time I was born, so I have no idea what the byte alignment on that was. Then data was then read in with a more recently written program, using what looks to be c++/MFC. This application doesn't do anything fancy, just reads the records into a structure: lRet = hDataFile->Read((char *)&Dfr+512, Dfr.Hdr.RecordLen-512); I suppose i'll have to do some testing using the trial and error method to see what I get. Edit: I did some digging. I remembered the old application transferred data, and all logging was done on the windows side. This means it had 1 byte alignment, but now that's probably out the window (no pun). Does this imply I will have to write element-by-element and cannot just flatten a cluster?

Thanks, I will try this. I don't have a sample file yet, but I will be getting one. I was going to use write to binary file which allows the swap to little endian (what I need for this application) but that is a good point about the flatten/unflatten from string. I will take a look at that. Thanks!

Sorry, this topic title is awful, but I will explain what I want to do here and look for feedback and suggestions. I have a bunch of different record types, each one has a "format for file" must override method. So my heirarchy looks like this: Record base class, with record children A, B, C, D, E. I have a method to send a record to my logger. I want to be able to send A, B, C to this logger, but I do not want to be able to send D or E. If D or E is used should always be passed into C first. When C writes to a file, it calls D or E's format for file VI. Now, my initial thought was to pull D and E outside this inheritance hierarchy, that way they could not be sent via the "send record" method. But, these classes still need a way to be formatted for a file, so I end up creating another class hierarchy with seemingly duplicate behavior. This may be correct, but I was curious if there is a more straight forward way around this.

Edit: Wrong forum...this can be deleted

I have some existing code that writes to a binary file. We are trying to move this to LabVIEW so that our log files will be in the same format as those in the existing system which we are replacing. in an email from our customer, I got the following: "The application was built with the byte alignment option set to one" Dfr.Hdr.RecordLen = 512; WriteFile (DfileHandle, (char *)&Dfr, Dfr.Hdr.RecordLen, &byteswritten, NULL); dfr is a structure, that contains a small header structure and a union of other structures based on the particular record being logged. The union stuff I'm not concerned about, as I'm rewriting this with LVOOP and I have record types as different classes which will "format themselves" to be logged. I'm quite positive that I can't just typecast a LabVIEW cluster to a byte array and still have this work, so I am assuming much of this formatting will have to be done manually, including padding/aligning the data. I am looking for direction as to first steps to take to make sure I'm not overlooking anything. If you need more information please let me know; I just put in the bare bones of what I thought would be enough.

Unfortunately, I can't contact Microsoft to have them change their IE Active X component , so I'll just have to live with it.

The first attempt I made was not good and is more of an example of what not to do than what to do. And honestly, I'm not sure if I have it anymore but I'll check later if I can dig it up. I will say, before the test I never felt completely comfortable. I was always in a serious time crunch, and I don't know if I ever finished the practice exam in the 4 hours allotted. I was crammed for time at the end of the actual exam also. So, if you're waiting for that "ok, I'm ready" feeling, you probably aren't going to ever get it! What I found helped the most was practice as best you can and realize that in your day-to-day job you have most likely done things far more complex and those things will prepare you better than any amount of practice can. If, through your code, you can get across to the graders the point that you know how to architect, I am sure you'll be good to go. Again, I'll see if I can dig up some of the practice stuff I did, but later attempts were purely regurgitation of the solution, so they probably won't help you too much, if I even still have them.

I agree -- the design is not something I would ever use in the real world. I forget which CLA example I looked at (is there only one?) but I do remember it is very consistent/misleading as far as what is important. They implemented an entire error handler if I remember correctly! I would suggest not doing this on the test. IMO an error handler "shell" with comments will suffice. You may find actor oriented solutions to be the best solution for the problem, but is it the best solution for passing the test? These two things are inherently different (especially when there is a time limit) and as engineers we always want the best solution to the problem. But, now we find ourselves thrown in a situation (just make it "good enough") that completely contradicts what we have been molded to do! It's a difficult balance, but I trust you'll find it.

Here are my steps for success. One of them is "don't try to be a hero." I think this point will help save you some time.

First off let me say, I understand sending any sort of heartbeat in a timeout case is not a good practice. What I am looking for here is why this is happening. I am launching a VI in its own loop using the "start asynchronous call" VI. The launched process then loads a large HTML file into an ActiveX web browser. When this loading happens, the event structure of the loop that originally did the launching doesn't timeout and no heartbeat message is sent. Can anyone speak to the reasoning of this? Is the event structure somehow being blocked by the ActiveX doing stuff in the UI thread. At first I thought my whole application was hanging, but then I pulled the heartbeat out into its own loop that sends it every 100 ms and the problem went away. It is obviously related to the event structure itself. The included VIs and HTML file reproduce the problem. Thoughts? timedelay.zip

I thought about this, but I didn't know if this was a code smell for something that's not correct, causing me to manipulate connector panes purely to force something to work.

It isn't exactly what I'm looking for but it brings up another point. This is showing an actor that is strictly tied to one type of acquisition: analog acquisition with buffered inputs. One of the things I have issues with when abstracting DAQmx is how to organize the different layers. Should all analog tasks (temperature, pressure, strain) inherit from a base class "analog task?" Maybe, maybe not. Are there enough similarities? Sure, they are all voltage, but what if temperature is only going to be single point, software timed acquisition while the others are buffered? At this point, does it still make sense to inherit? You can no longer have a dynamic dispatch "read" VI because some tasks will return an array, others a single value. So, you can make a polymorphic VI, but then you are back at square one if the wrong instance is selected: run time errors. You could break them off into their own processes for each different type, but now there is no reason to have inheritance at all, because they will all be in parallel. In this case each process manages one, and only one, type of acquisition.

I'm just curious if any of you have successfully wrapped DAQmx into LVOOP classes (on an application specific level, not wrapping all of DAQmx functionality), and what you have found to be most effective. One thing that troubles me about DAQmx is the lack of safety between the type of acquisition and the DAQmx reads, which manifests itself in run time errors. For example, you may have set up buffered acquisition when you create your virtual channel, but that doesn't stop you from wiring a single point DAQmx read up to your task, resulting in errors at run time. This is just one example. I am not looking for an exact solution, but I am just curious what other people have done in their code with regards to providing themselves with an application specific DAQmx classes. Possible inheritance hierarchies, what pertains to the base class and what pertains to the child classes, if you even care about any of the issues I've stated above in the first place, etc.

LabVIEW Limericks?

I went back and reread your question...sorry, I was misunderstand a bit of what you were asking so my response isn't quite in line.

I usually go with something like #2. I can see some drawbacks. For instance, new messages won't be handled until states queued up due to a previous message are finished. But, currently I have found this to be best *for me* (without the inner while loop). The drawback I mentioned can be somewhat mitigated by the following: I use the state (job) queue to handle routines (startup, shutdown, reconfigure) etc; routines that you usually don't want new messages to be handled while they are happening anyways. Then I try to handle all other incoming messages in the inner case structure, right where I get them; I get the message, I do what I want with it right there. This also keeps me from having to make message data, state data, which can clutter things up fast. Adding things to your shift register just so it can be processed in a different case seems dirty. If it is any sort of long processing state, or state that could backup the incoming messages, I dish it off to another loop and continue on. Edit: If the same processing needs to be done for multiple messages, you could have a state and just queue up that state. But I prefer to have a subVI and put it in multiple places. This keeps things clear as to "I got this message, this is what I do with it" and doesn't send other developers inherting your code on a rabbit chase, following state transition to state transition. Yes, it may cause some code duplication, but In this case I'm find with it. Again, my opinion

So I can visualize, are you talking like the class hierarchy window, although the ability to move the classes around to define inheritance, rather than going into the properties dialog and defining the inheritance structure in a tree control? Edit: I should read more carefully -- The Symbio and G# UML tools make an excellent stab in that direction.

I was able to reproduce, but I'm not sure it actually submitted. I may have set things up to automatically submit (is this possible). I got the "investigate now" dialog when I started back up and I tried that but no resolutions were found. When I clicked the next step which is email NI, my browser won't load the page it's trying to. Anyways, here are the dumps (I reproduced the crash twice), let me know if I need to do anything else. 37b0f495-ea89-4006-8e97-8956f0e56de4.zip 11118694-6d91-4999-abe6-c7de5aa012ac.zip

I had a bunch of them yesterday as I was trying to troubleshoot. I can't remember which one I actually submitted, because I know I didn't submit it every time while I was troubleshooting. Unfortunately, I deleted the "bad classes" from SCC and added the new ones to make sure there was no confusion. I'll get them back reproduce the crash, then submit and make sure I get you the right GUID.