ShaunR

Don't get me wrong. you can have stateful FUNCTIONS. I'm saying that the HANDLER should not be stateful. Sending a message should execute a function every time rather than conditionally executing if a message was received earlier....... there be monsters Nothing to stop you having a class in a frame that maintains its state but it should be encapsulated within the scope of the function, not the handler or, even better, just don't send a message at all (it depends what state we are talking about- file open, read,close........bury it in the function. Move slide if position is greater than 3mm, thats a sequencers job and it shouldn't send "move"). The TCPIP code I placed was just a quick and dirty way of sending commands. From experience it is quite adequate for the local loop at medium rates (10s of ms) or for an internal GB network of hundreds of ms, but forget it for internet or high speed comms. It is also useful if you are talking to many destinations with short packets infrequently (e.g. 50 cRIOs with "RESTART"). It is up to the developer to define the functions and features, the handler just provides a messaging interface. I think I said earlier that in the real world I use a comms handler and can send via a number of methods. That module actually maintains connections (whatever the interface) but I have made it function so that they die if not used for a couple of minutes so if they are used often they persist, but I don't have to explicitly close them. You can do whatever you like in the handlers, just KISS 1. Actually. The generic symantics are TARGET->SENDER->CMD->PAYLOAD. So no. It's not loose. Target and sender are purely for routing. It could have been Destination IP address and Source IP address but for this implementation I chose VI names and relieved the burden on the user of typing in the sender on every message. Additionally, you don't have to use queues. It's just convenient that queues can be isolated by names so the target is consumed for that purpose. Queues also break the need for wires running all over the place, or shared storage (which is required for events). You could have used TCPIP primitives in the Send instead of Queues and it would have worked much the same way directly over a network (which is pretty much how dispatcher in the CR works). In this respect it is a messaging strategy realised with queues and handlers. But the messaging itself would be identical with TCPIP listeners and opens. This is what makes it easy to traverse boundaries both in hardware and in software languages since it could be a webserver written in python at the other end (not easy to do with labview coded messages). 2. Well. You can't beat discipline into programmers. Only the army can do that But you have perhaps missed the "reuse" aspect. Once you have a TCPIP handler, for example, then why do you need to rename it? It's like renaming Lapdog. Besides renaming is just a search and replace string on all VIs. Not as if you have to go and rename a shedload of VIs,and have to re-link all over the place is it? 3. I don't understand the question. There is no TCPIP display loop. There is a TCPIP handler which happens to be showing its panel. And there is an IMG handler. The listener just forwards the message using Send.

I'm no expert in VB but looking at the VISA programming manual, references are usually passed as Byval Value& (notice the ampersand) e.g. C Syntax: ViStatus viGpibSendIFC(ViSession vi) Visual Basic Syntax: viGpibSendIFC&(ByVal vi&) The C pointer (asterisk) makes me tentative, however, since it could be a ByRef. But it is unusual. Hopefully Rolf will be along to answer definitely (he's the guru on this kind of stuff, I tend to work the other way around - Labview->C)

The non-labview thing I found interesting was that cats operate time-shares on their territory if they live closely packed together so they don't have to meet each other. If only I could get my neighbour to co-operate like that!

Not exactly what you are asking for but it may be suitable even if not perfect (case select-it uses the JKI plugin framework). Alternatively, it would be a very good starting point for your own framework plugin.

The vision toolkit is for, well, vision (images, OCR, camera feature detection.etc) I would take a look instead at the Robotics toolkit which has path planning, obstacle avoidance, directed graphs etc.

The IMAQ Spoke might be worth looking at

Indeed. In fact, if you can put a file write in the send (i.e. save the message with a timestamp) you can load it back up and playback a recording. If you match the timestamp with an error log, you can replay everything the operator did to replicate an error I'm not sure what you mean by "infer" the message type. You "know" what the type is for each message payload (it's planned) so you "know" what to unflatten with.if it's non-stringy. It's no different from "knowing" what get message to place in each frame in the lapdog example but without having to have VIs for every labview type you are going to support. It's just data seralisation.

I think it just looks like the JKI because it uses delimited strings and string cases. There is no state, the strings are hierarchic and atomic so it is much simpler. That is not to say you could not build a QSM style handler, but I highly recommend not to and instead think in terms of atomic functions associated with strings. I think it is more akin to SCPI in that it is hierarchical messages. If a single string is unintuitive, just add another [payload/data/DaklusStuff] terminal and concatenate inside the send. The advantage of a single string is that it's easier to document (scan diagrams and list messages) and create scripts. Although the former goes out the window when you start dynamically generating the messages. No. It's part of the messaging strategy and key to the routing. It allows you to modularise the code to effectively create an API messaging interface whose "address" (or target as I call it) is defined simply by naming the VI handler (it can be extended for clones too, but this is an example). It helps, of course, if the "target" describes the modules' capabilities (like DVM, FILE, DB etc) and that would be a "convention" I practice since it allows conversations such as: FILE->LOAD->c:tempcfg.cfg DVM->SET->VOLT->3.9 DB->QUERY->SELECT * FROM test;

Maybe. But you should note that in the presentation, his FGV singleton is a singleton (because all VIs are singletons-unless re-entrant) but he is incorrect that this is enough to fix the race condition in his anti-pattern (i.e. he hasn't fixed it and it isn't atomic). The FGV must contain the read->write for it to be protected by the VI boundary

Ah. right. (Sorry Daklu). I'll go and fix that in a bit OK. Fixed. Don't have to register (I'm always logged in so didn't notice you had to).

It looks on the surface like you have the LabVIEW equivalent of mixed metaphors. The general method for a singleton pattern is to check in and out rather than for loop memory and semaphores (which is a classic LabVIEW kind of thing you might do in an action engine, although all VIs by default are singletons so you wouldn't need the semaphore) This may help as may the singleton pattern example in the examples dir. You don't have to worry about "threads" or "thread safety" in labview. I think you mean "race free" singletons..

Well. That's not obvious since I can't find out how much I'm using and the error message is "You can upload up to Uploading is not allowed of files (Max. single file size: 50MB)" It was fine before the downtime yesterday and I've just deleted 2 of my CR submissions (>1 MB) and it still won't work (the example is only 75KB). So I don't think that is the problem (unless you are just intimating that I have to pay to help someone-bleh).

@Daklu. I downloaded the lapdog and it looks like I was mistaken as to what it was (my fault for jumping in-apologies). From this and previous conversations, I had somehow got into my head that it was a messaging system (kind of like the Actor Framework or Data Broadcasting Library). It looks, however, like it is a queue wrapper which is functionally identical to my queue.vi (but I don't bother with types). @ AlexA So I've taken the lapdog stuff, ignored all the types and written a cut-down version of my stringy messaging using the lapdog as the core rather than my queue.vi.(they are virtually interchangeable). The messaging itself is fairly topology agnostic (onion, chained, star etc) since it basically depends on how you put the strings together and how you disassemble them (just concatenate to onion route). I cobbled together an example in light of your requirements to so you could see how I would put Lapdog to use for message forwarding accross TCPIP. From this point, it becomes the programmers preference as to what to do next (I, for example have a COMMS.vi instead of TCPIP.vi which uses the transport.lvlib to give me TCPIP, UDP, Bluetooth and websockets and the UI would communicate with an additional layer rather than directly so that sequencing and application state can be accounted for). The routing, mechanism, however, is there in it's entirety (you will see that VI names are used to provide unique queue name/message routes). That's the easy stuff. The hard stuff is responses if they are required (for which I use events).. (Hmmm. For some reason I cannot upload the example-something to do with the downtime today? Here's a download link instead: Stringy Lapdog Example)

Spotted this on UK TV. LabVIEW used for cat tracking (Horizon BBC)

From Daklu? (pretty much my position on LVPOOP even though it's python). Only a quick hijack......apologies.

The IP to string defaults to looking up the domain name (which the cRIO probably doesn't have). You are probably seeing the domain lookup timeout. Set the "dot notation" to true and it should be OK.

+1 That's why I wrote transport.lvlib and dispatcher (which uses the former). I've never liked NSVs. Fine in theory (event driven) but too bloated and difficult to manage/maintain even if they did work properly all the time.

Silly question that has to be asked. Have you checked the firewall?

I think you'll find I didn't comment on your suggestion before at all. I just shut up because I was told to stop reading because it was POOP. They are talking about Onion and Chain Routing of messages. The former is (in your terminology) an envelope inside an envelope inside an envelope ...ad nauseum. The latter is an envelope with a friends address with a "please forward to this other friend ".....ad nauseum. I'm just suggesting they just send it directly to the recipient by using a dispatcher. I have no idea how it would be implemented or what your "envelopes" do. I'm sure Daklu would come up with an elegant solution given the description if it was viable. For me, it's just a case of using a keyword in a string and making sure something is listening for it but the principle is the same. Therefore it is Chain Routing with a fixed 2 level depth.

Don't know much about this API so may be missing a fundamental implementation aspect here. But if you have a "RouteTo7813R message" (which you presumably you must have for a reciprocal receive case). Is there a reason you cannot have just one wrapper layer (lets call it "Router") and all it does is, well, route? The arguments could be Target, Sender and Payload Message.

Rule 36 & 38 You have a timeout of 5000ms in two locations, so it's not definite that the open is failing from that. But if you follow rule #36 and #38, you will have a better idea what is happening and you can show the error with the Simple Error Handler at the end..

1) I am very smart for very short periods with very small pieces of code and have a FIFO memory retention(without google ). Therefore my LV utils toolkit is very smart and I just have to be clever enough on a daily basis to remember which part of the toolkit solved that problem last time. It's the difference between being smart and being experienced 2) I architect my code at a level well below my abilities since debugging is twice as hard as writing code and therefore I'm not competent enough to debug code written to my ability (to contextually quote Brian Kernighan). Oh. and a framework is an architecture without the important bits (quote: ShaunR)

My definition of "Code Smell" is completely different to that in the article. To me it is a behaviour that indicates a particular bug or type of bug. They are already here if you are talking about pre-processor commands - Conditional Disable. But I feel your pain, not necessarily with FORTRAN, but certainly C where everyone has their own definition of INT and "macros" that can be considered cryptographically secure.

Ditto what hooovahh said (for right click menu). If you just want to copy the text from one location to another, use the edit/cut/paste in the labview main menu which are mapped to Ctrl+C, Ctrl+V etc. It may seem a pain for things like a text control where you are used to windows copy and paste on a right click menu, but it makes more sense when you are copying entire arrays or clusters.

+1000.