ShaunR

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

@ShaunR Huh, that's really cool, I've never thought of attempting to script control of my VIs like that. Though, now that I think about it, it makes a heap of sense for testing everything. I wonder if you can use VI scripting to parse the list of cases in a case structure (just checked and you can). Cool, you could write some sort of automated tester that grabs all the message names a VI expects from the case structure Framenames, then trys to send them different messages.

 

I guess this is the point of making everything a string, but with LapDog I can't see how you'd programmatically infer what type of message should be arriving in any given case so it could be generated. I guess there might be a way to crawl one of the message libraries and try to just send everything in there... I dunno, just daydreaming now. 

 

@Daklu This is not really the right place to go query this, but I was just wondering why you didn't do the required casting for the various messages within each "Get XXX Message.vi"?

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.

Thanks Shaun.  It looks like you use a similar technique as the JKI state machine. 

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.

It's much easier for me to understand when I separate the message ID and payload.  Packing everything in a single string hurts my brain too much. 

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.

Do you use the vi name to name queues as a matter of convention?

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;

That article is a bit confusing...the SEQ version seems interesting and has built in mutexing which is nice but I do not understand the warnings about its use.

This helps to clarify the options...

 

https://decibel.ni.com/content/docs/DOC-20865

 

It looks like I probably should just encapsulate all my R-M-W operations into class methods that use the IPE wrapper and get rid of the semaphore mutex

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

Shaun, I think Daklu is referring to the need to register on your site in order to download the example.

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.

What so bad about 'thread safe' singletons anyway?

You don't have to worry about "threads" or "thread safety" in labview. I think you mean "race free" singletons..

What?  I have to register?  Bleh...

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)

Horizon discovers what your cat really gets up to when it leaves the cat flap.

In a groundbreaking experiment, 50 cats from a village in Surrey are tagged with GPS collars and their every movement is recorded, day and night, as they hunt in our backyards and patrol the garden fences and hedgerows.

Cats are fitted with specially developed cat-cams which reveal their unique view of our world. You may think you understand your pet, but their secret life is more surprising than we thought.

It WAS POOPy!  I was protecting you.

From Daklu? 

This is driving me even more bananas!

 

I have the cRIO spitting out UDP packets every 100 ms, which I can successfully read on the PC using a simple Python script.

 

The picture attached is my attempt in LabVIEW. It successfully reads the first item, then the iteration count only increments something like every 9 seconds and the received data is incrementing correctly, but way way too slowly. In the LabVIEW IDE it basically locks everything up, and in an executable it doesnt freeze anything but still behaves strangely.

 

Strange indeed.

 

EDIT: figured it out, it was the IP-->String that I added during debugging the firewall issue that causes the slowdown. Removed that and viola! Working as expected. Time to go to bed...

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. 

Our general consensus on NSV: Critical stuff - don't use them. Non critical - sure, use them (but you already have other comm set up for the critical stuff so why not just use that   ).

 

I don't know the exact number, but at some point we have noticed NSV issues when you get large numbers of them on a system. 

 

I have recently written an object based TCP client/server so I just use that for everything now. Once it's written, you don't have to spend time writing tcp communication again. IMO your time is better spent doing something like this to avoid potential headaches down the road, and scrap NSV all together.

+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.

Grrrr. UDP is driving me crazy today.

 

I have a cRIO which I can communicate just fine with (LAN connected).

 

I can transmit UDP from the cRIO to itself, and from the PC also to itself, but I just cannot get any UDP datagrams to be seen by either end of the system (i.e. PC --> cIRO and vice versa).

 

Wireshark tells me the packets transmitted by the cRIO are reaching the PC, just LabVIEW returns nothing from the UDP read function.

 

 

 

The only think I can think of is something is throwing a wobbly due to the the multiple NICs in my PC. I have tried to force the UDP Open on the receiving end to use the NIC of the ethernet connection that I know I am using.

 

ARG! I think its the windows firewall!

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

He’s actually using what I call “Outer Envelopes”.  You didn’t like them when I suggested them before.   In fact, I use a “Send Via TCP” outer envelope in my TCP message system.

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.

you still need a RouteTo7813R message handling case in your RT TCP Receive loop. 

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.

Thanks ned,

 

Well, I want to pop up some message when my VI cannot connect to the server.

I noticed that when if the VI could not reach to the server, the udp open will timeout. ( I knew because my connected button lag for input timeout 5000ms if it cannot connect)  but I don't know why the error out wire doesn't give me any error output. maybe I do something misunderstand about error handler. any example vi about that?

 

I think it will be the simplest way to check the connection if I can get this error out.

 

thank you.

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.

Let me just state now, for the record, in some future LabVIEW where such features exist,

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.

And, honestly, I think the project tree would be a better environment for defining PolyVIs

Hi Ton

As I understand it, 17025 (like the old ISO 9000) is really a quality documentation exercise. So as long long as you can "argue" the case with documentary evidence, I don't really see that you cannot be compliant. Of course, if you normally rely on proxy validation (our box is certified and within the certification date, therefore this measurement is certified) or you usually use an accepted standard procedure, then it is a lot more work as you have to detail the methods, quantify measurement errors and get them signed off by an accreditation authority.

In your case, the key here is probably:

Documented in-house methods based on standard specifications; this category makes up a major part of many laboratories’ scopes since it avoids the commitment of being pinned to the fine print of the standard specification whilst maintaining the credibility provided by the standard specification. Placing an in-house method in this category will generally reduce the amount of validation which a laboratory has to do. The degree to which this is true, however, will depend on the extent of the departure from the standard specification. Care needs to be taken, when reporting data from

such methods, to recognise the variation from the standard specification. It is also necessary to ensure that clients are aware of the variation and accept the resulting data as still being suitable for their purposes.

embedding Python into other systems (like here in LabVIEW) support for the latter was considered highly unimportant and various discussions about improving that interface where shutdown as undesirable.

That has been my experience with the entire Linux community. When you get the answer "install linux" in answer to any windows question - You just wonder what they do as a real job.

50 feet should be fine. The "rule of thumb" is Less than 100 feet is "usually" OK for most thermocouples.

Ignoring interference, impedance matching and cold junction compensation, It basically boils down to the total loop resistance.

The total loop resistance is a calculation based on the diameter and length of the thermocouple wires. Thermocouples usually have an impedance per foot/meter parameter and the thermocouple loop resistance should be less than about 50 ohms (don't forget 1 foot off a thermocouple spool is 2m of loop wire). You will notice in the NI-9211 spec there are compensation values for impedances greater than 50 ohms so it doesn't mean you cannot use greater, just that compensation must be applied. There is of course a maximum limit due to the sensitivity of the input circuitry, but you should be fine as long as you are not using wires the size of a gnats whisker. 

So which idiot didn't order RTD if the temp range is 0-60 degC? 

Hi shaun R,

                  No,it is a color image.

 

 

Regards

MADHUBALAN

OK. Maybe you have taken a colour image, but you have taken a colour  picture of a grey object against a grey background. The dominant colour will still be "GREY".

A quick and dirty (although not foolproof) method is to just look at the mean of each colour component.

A better but much more complicated method is to use K-means clustering.

I don't know of any LabVIEW examples off-hand, but here is one you can translate from Python.