ibbuntu

QUOTE (ibbuntu @ Mar 27 2008, 07:02 PM) I went back to using Shared Variables and LabView has stopped crashing. My code now works. Thanks to all who replied.

QUOTE (ibbuntu @ Mar 27 2008, 10:33 AM) Ok it appears I had some messages clashing. I have now re-written the code to use the dstp protocol. The code now crashes LabView, but when I run the debugger to find out where it crashes, LabView doesn't crash. What could be causing this? I would provide more information, but I don't know where to start. (Getting very frustrated now). Tom

Thanks for all your replies. I have been busy at work on my code, as I only have 2 weeks left before the experiment starts (I started writing the code in October, so it's not last minute, it's just taken me a long time to get to grips with writing such a large program in LabView using many varied techniques). As I didn't have time to understand and implement your code Eugen, I decided to modify my code. I now have implemented code to prevent message loss. When I send a message, I check to see if a "received" message has been written to the variable, and if it hasn't then I send the message again (after a 100ms delay). Now I don't lose any messages and the code works the way it should, apart from the fact that it runs slowly. The loop which sends the messages has to run many times before a message is sent by the client and a "received" message is received from the server. This is variable, sometimes it will happen first time, and sometimes it can take up to 100 times to successfully send the message. I can't cope with such long delays in my code. Any ideas? Thanks, Tom

QUOTE (Eugen Graf @ Mar 20 2008, 11:41 PM) Thanks for that, this does look like exactly what I am trying to do. I will have a look and see whether I can incorporate this into my code. I guess I am suffering from this problem with my implementation (from the wikipedia page): QUOTE As a first example, many pub/sub systems will try to deliver messages for a little while, but then give up. If an application actually needs a stronger guarantee (such as: messages will always be delivered or, if delivery cannot be confirmed, the publisher will be informed), the pub/sub system probably won't have a way to provide that property. In my application I do require the guarantee that all messages will always be delivered, as my system requires the messages to undergo transitions in state. Such as going from a state of waiting for path information to a state of capturing data and saving to the provided path. Tom

Hi, Firstly sorry for the length of this, I have tried to be as succinct as possible. I would appreciate any suggestions anyone might have. I have been writing code for a while now to use for collecting data in an upcoming experiment. At the core of the code I am using shared variables to pass messages between the different computers on the network. The messages are small, they are a cluster of 4 strings: From, To, Type, Message. The Type field is the type of message being sent e.g. Register, Status, Enable and the Message field contains any extra information. To pass the messages I have a loop which reads the shared variable and checks to see if it has changed since the last time we read it (using the timestamp), it checks to see whether it is relevant (i.e. whether the To: field corresponds to itself) and as a further check which I added later it checks to see if the message is blank. If it sees a new message it adds it to a queue and writes a blank message to the shared variable. This is the server side, on the client side a message is sent by first checking to see if the message stored in the shared variable is blank, and then writes a message to the shared variable. This system works well when there is only one object sending and receiving messages from the server, and if it is running on the same computer. However the object is on a different computer, or there are many objects communicating messages are somehow lost and the system grinds to a halt. This can occur if a client is waiting for some information from the server (say a path for it to save its data to), and the message that the server sent was not received, the code will simply sit in an infinite loop waiting for the data. I originally coded this using plain shared variables, with one for messages coming into the server and one for messages going out of the server. This worked ok, up until I had about 3 things communicating with the server. I decided therefore I would try using one shared variable per object instead, so that I couldn't have the case that two objects were trying to write to the shared variable at the same time. For reasons I won't go into this meant I had to change from using shared variable reads and writes to using the datasocket vis to read and write data. Upon doing this the number of lost messages has increased and the program performs even worse than it did before. If you got this far, thanks for reading this. I'm really at a loss for what to do, so any suggestions are welcome. Thanks, Tom

Just a random thought: Wouldn't it be nice if when you right-clicked on a class' wire there was a menu option to insert a method vi of that class?

It turns out it was a known bug. The fix was: "The first time you load the private data control in 8.5, open the front panel and resize any control in the private data cluster before saving. This puts a change on the VI so the class knows to update the save image." I'm now (finally) enjoying the new features in 8.5 and using a lot more accessor methods, which I tried to avoid like the plague as it was such a hassle before. Whether this is a good thing or not I don't know (see http://www.javaworld.com/javaworld/jw-09-2...5-toolbox.html) Tom

Hi, I am using shared variables to pass messages across a network. Every time I open my project my vis are broken due to this error: "LabVIEW could not generate code for the shared variable. You must open the VI in the project that contains the library where the shared variable resides." The only way I have found to fix this error is to double click on all the shared variables on my block diagram, after which the error goes away. What's going on, and how do I stop this from happening? Thanks, Tom

Hi, I upgraded to LabView 8.5 on Friday. Had a quick play with it, opened my project from 8.2.1 had a look at some of the new oop features. Then closed it and saved it. Now when I come back to open it again this week Labview crashes on opening it saying: "Fatal Internal Error : "LinkObj.cpp" line 714". I also can't open the project in LabView 8.2.1 now as it says that the file version is later than the current labview version. So I tried creating a new project in 8.5 and filling it with all my old classes, however this doesn't work as on adding the old classes LabView either crashes or the class is locked and it is apparently not loaded. Here's the error log created when trying to open the project in 8.5: #### #Date: 22 Jan 2008 12:07:31 #OSName: Windows NT #OSVers: 5.1 #AppName: LabVIEW #Version: 8.5 #AppKind: FDS #AppModDate: 07/24/2007 20:07 GMT c:\builds\penguin\labview\branches\Jupiter\dev\source\linker\LinkObj.cpp(714) : DAbort: Attempting to remove [LinkIdentity "Astra-Gemini network controller (server).lvclass" [ My Computer] already on the close lists that close operation DID NOT APPROVE. T $Id: //labview/branches/Jupiter/dev/source/linker/LinkObj.cpp#80 $ 0x00BC3287 - LabVIEW <unknown> + 0 0x00DAC519 - LabVIEW <unknown> + 0 0x00DAD2D7 - LabVIEW <unknown> + 0 0x00DDF141 - LabVIEW <unknown> + 0 0x00DE10D6 - LabVIEW <unknown> + 0 0x00DE13DD - LabVIEW <unknown> + 0 0x00DE5B58 - LabVIEW <unknown> + 0 0x00DE5B88 - LabVIEW <unknown> + 0 0x00DE5B88 - LabVIEW <unknown> + 0 0x00DE5B88 - LabVIEW <unknown> + 0 0x00DE5C05 - LabVIEW <unknown> + 0 0x00DF8C26 - LabVIEW <unknown> + 0 0x00DFB749 - LabVIEW <unknown> + 0 0x00DFC240 - LabVIEW <unknown> + 0 0x00EE0DB5 - LabVIEW <unknown> + 0 0x00EE117F - LabVIEW <unknown> + 0 0x00EE4A55 - LabVIEW <unknown> + 0 0x005DC9CF - LabVIEW <unknown> + 0 0x005DCAC3 - LabVIEW <unknown> + 0 0x005E048F - LabVIEW <unknown> + 0 0x005E176B - LabVIEW <unknown> + 0 0x0049C139 - LabVIEW <unknown> + 0 0x0049A981 - LabVIEW <unknown> + 0 0x0049C1EC - LabVIEW <unknown> + 0 0x00405678 - LabVIEW <unknown> + 0 0x0040599B - LabVIEW <unknown> + 0 0x0045CFF6 - LabVIEW <unknown> + 0 0x00505D85 - LabVIEW <unknown> + 0 0x00505FAB - LabVIEW <unknown> + 0 0x00505FF0 - LabVIEW <unknown> + 0 0x0149415F - LabVIEW <unknown> + 0 0x7C816FD7 - kernel32 <unknown> + 0 0x00000000 - LabVIEW <unknown> + 0 What are my options? Thanks, Tom

QUOTE(Aristos Queue @ Jan 19 2008, 03:11 AM) Well thanks very much for your replies, and keep up the good work! We just got Labview 8.5 on our servers yesterday, so I'm looking forward to using the new features. Tom

QUOTE(Aristos Queue @ Jan 17 2008, 06:58 PM) Yes I do modify the value of Network Controller. That's the whole point of the design, the Message Handler objects are responsible for containing the code to handle the message, however it may be necessary to alter the Network Controller's state depending on the message. For example I have a "Register" message, which will create a "Register Message handler" in my "load message object" factory vi. Then we call Register Message handler's "handle" vi which calls the Network Controller's "add instrument" vi, and the instrument that sent the register message is added to the Network Controller's list of registered instruments. Why is it not possible to track the path of the object through the subvi, using some special terminal similar to the dynamic dispatch terminal? Tom

QUOTE(Aristos Queue @ Jan 17 2008, 04:57 PM) Don't worry, I intially solved the problem by removing all dynamic inputs, but then later realised exactly what you just pointed out, so I went back to the front panel and made the input dynamic again. However the wires on the block diagram didn't seem to change back to ones with a grey border. So I went back and started again, here is a picture of the original problem: and this time I simply removed the dynamic terminal output and left input as it was. This now meant that the connecter panes in its parent VIs were different, so I changed those to only have a dynamic input, and changed my output object to give: it appears that unless both the input and output terminals are dynamic dispatch the wire does not have a grey border. Tom

QUOTE(Aristos Queue @ Jan 16 2008, 10:12 PM) Here is a picture of my block diagram: I have now removed the dynamic inputs. The problem occurred at handle.vi when I passed in the network controller. I assume this solution will work, but it looks ugly to me and I was worried that perhaps there is a problem with my design. Tom

Hi all, I've run across a problem when trying to implement the Specification design pattern. My problem is this, I have a class called "Network Controller" which I am using to handle messages being passed over the network (I use the LabView shared variable to pass messages as clusters of strings). Now I decided that I would like to encapsulate the code for handling the messages in a seperate class "Message Handler" which has a method "handle message". This vi could then be overridden by children of "Message Handler" to deal with specific types of message. The problem arose when I tried to implement this. I decided that "Network Controller" should have a list of subscribers, and they would subscribe themselves by sending a "subscribe" message. The network controller then takes this message and uses a Factory to create the corresponding child class of "Message Handler" in this case "Subcribe Message Handler" which can then run its "handle" vi to add the subscriber to the list. However I cannot pass the "Network Controller" object to the handle vi without the vi breaking. I get an error message saying "One or more of the inputs to this tunnel or shift register does not originate at the dynamic input front panel terminal". Now I could just use a get function to take all the data from the "Network Controller" and pass it to the vi that way, but that's not really what I want to do. I want to pass the "Network Controller" to the Message Handler's "handle" vi so I can use its methods. The idea behind this design was so that I could simply add functionality to the "Network Controller" class if I decided in the future to pass different messages across the network, by simply adding another child class of "Message Handler", which the Factory would create given the name of the message. I didn't want to do this by using children of "Network Controller" as that didn't seem to make sense to me. A "Subscribe Message Handler" class is not a type of "Network Controller", but it should be able to provide functionality to the Network Controller. Any thoughts? Thanks, Tom

QUOTE(jdunham @ Nov 29 2007, 08:16 PM) Ok, I've had a go at creating a "view data" method and using a sub panel to add it to my main front panel and I've found that it doesn't work because a sub-panel requires a reference to a re-entrant VI and Dynamic VIs cannot be re-entrant. Is there another way to achieve this? [EDIT Ignore this, I was referencing my VI wrongly. I've now got it to work! ] Tom ps. I suspect we have moved on from the original topic of the post. I am new to these forums, how should I go about changing to a new topic whilst still keeping the thread?