ShaunR

It's not directed at us (engineers). It's a sales pitch to internal profit centers with the hope that external LabVIEW engineers will use the arguments to their upper management. In essence it is "this is good for both of us, but mainly us, and means we will listen more, maybe". You will notice there are no concrete or tangible benefits to anyone other than NI. However I don't think this brain-wave coming directly after NXG being killed is coincidence. What is clear is that their mind is made up and now it's just a case of managing the PR. "The beatings will continue until morale improves" - Captain Bligh in Mutiny on the Bounty

Then the hard work is done. The FPGA in that project was to implement the MIPI receiver. If your camera is giving you the FPS you need, then it's just post-processing you are interested in? You are already in the analogue domain so why not just use comparators for that? They are cheap and have can have nanosecond propagation delays. Unless, of course, the image acquisition ADC is not as bare-bones as I am envisaging. Where I'm going with this, though, is to do as much as possible in hardware but I can see the attractiveness of a general purpose FPGA. I would ordinarily suggest the so called "Smart Camera's" which are excellent bang-for-buck with these kinds of requirements and have a lot of the features that LabVIEW has but your sub msec requirement prohibits most of those.

I'm not sure you will find an off-the-shelf solution to this. Sub-millisec means a frame rate over 1000fps before you get to any processing. I'm not promoting this as a solution but you may find some useful information in this little project. Opens Source IMX219 Camera MIPI CSI-2 Receiver Verilog HDL Lattice FPGA MachXO3 Raspberry PI Camera mipi_csi_receiver_FPGA I'd also be interested in hearing more about your ADC solution if you can flesh it out more thoroughly.

I wouldn't bother, personally. It seems a poor solution. If I were to point to a problem with LabVIEW errors it would be resolution and they don't help with that. I did have a whole paragraph on what I would like to see as an improvement to error reporting and how to achieve it but I reconsidered in the face of LabVIEW still considering reading an entire file as an error and AQ's presentation.

I actually took it as an utter disdain for the time and cost of working around their deficiency. The presupposition that there was a work-around and I haven't told customers that we can't do it because LabVIEW doesn't support it. That the work-around would cost x weeks of project time to achieve (to the customer's surprise when they thought it would be par-for-the course) so the customer didn't order it. Or even an entire framework based on HTML interfaces was developed relegating LabVIEW to a mere back-end service (this also goes for his "Vector UI nonsense too). I'm sure the counter-argument would be the 3rd party tools that are available for internationalisation but that just shows that he's never tried to use them in a project or been called out to a customer site when they can't load a file because the filename is Unicode or suddenly everything has turned to Chinese characters. After all. We've only been complaining about Unicode support for a decade or so, right?

I'm not sure that was meant to be "Subscription model and related questions" but oh my god. After watching the full video I can safely say I would have walked out within the first 10 minutes. Not only was it not what was advertised but it was one big poll in a totally inappropriate format of "live". The lady that was incredulous about Unicode being so low was literally articulating what I was muttering at my screen. My muttering became shouts at this guy's response, which weren't family friendly. It's this kind of feedback gathering that is also responsible for all the inanely stupid political policies that are dreamt up with "focus groups". And when did "Service and Support Package" become to mean "Primary Software Sales Channel"?

I'm still none the wiser from that presentation but I will say it was probably too many Erics and not enough Darins.

Send an email to support@lvs-tools.co.uk with this info and we can start to look more closely at it. The next release has a lot more functions to deal with x.509 attributes so we can probably resolve this if we know what the NI OPC toolkit is expecting and make sure the attribute function is available to set them. With regards to the signature, those functions simply convert the byte array using the following code. So it seems strange that there is a disparity between the byte array and the hex string representation.

Just a heads-up. NI are offering Tools Network products the opportunity to move from the classic LVTN licence to a subscription licence. There aren't many details as yet and it's not clear whether you will lose access to the [separate] LVTN products if you don't keep up your subscription to LabVIEW itself, but it looks like everything will eventually be behind their subscription model.

I actually get this.

BBC Pidgin.

Except for all the in-place structures and array manipulation That won't save it in the i+j notation, hence my question. It also looks like the OP wants to interleave the data from the two graphs to get to his table when he could just have built the array the "old way" and sliced out the data for display.

The reason this doesn't work is because you are building a plot array of complex numbers and the Save To Spreadsheet accepts doubles. I expect what you were seeing was just the real part as the complex numbers were converted to doubles. Why are you building the array as complex numbers? Do you wish to save the data in complex notation?

I have to agree. The proxy indicator of Job positions also shows a rapid decline in Europe. Not sure if that is replicated in the US but I suspect it is.

No longer a stand-alone product. The Websocket API was rolled into ECL sans the FP and HTML library portion.

It's 8 months apart. I don't think it's a concerted effort to spam. It is useful to highlight products from time to time. Maybe we should have a commercial product sub forum for these types of products.

Yes. It's not a new idea, BTW. This is the route ladder logic went for state machines in PLC's. Ignoring the boiler plate scripting for a moment. What is really missing is an intuitive way to view a program's structure. I said a long time ago that we need something similar to (the now defunct) Firefox 3D View. This could be a mode of the VI Hierarchy diagram allowing us to inspect the way subVI's are interconnected and allow us to zoom in and isolate areas of interest. Event and queue [message] tunnels or the "Channels" could easily be shown which are invisible with the tools we use today.

Just to note. ECL doesn't support UDP at present. There are plans to support DTLS (the UDP version) in the future though, I won't comment any further than that except to say that I too would be interested in the comments of users.

I don't know why they continue to push these "place a VI that transforms into a mess of code". It always seems to me they are solving the symptom, not the cause, by automating the replication of boiler-plate code we have to do when the real goal is not to have to replicate at all. A long time ago I posted a VIM that, awkwardly, implemented "named events" and the "framework" was to use that and a queue with a bit of string manipulation to send messages back again. It was basically the the same as MessengerM, shown here. It would have been much better if the event structure could use named events (wire a string to the terminal?) and have an [optional] output on the right hand side for a message out/back. That would implement the MessengerM without all this malarky. Certainly in a lot of the event driven API's I now produce, there is a "Source" on the left side of an event structure. That could just be wired across to a "target" on the opposite side to send a message back to an individual stack (aka a queue output). Bonus points if the "target" can be marked as "broadcast" to behave as "Generate user Event". I dare say that it could be refined further with a bit more thought too, since what we have to do is figure out who sent the message and act accordingly-the event structure already knows who sent the event.

And when you do, there are still options

I'm a collaborator and I'm not sure I like that. I'd prefer to be in the resistance.

I think this is a very positive thing that more should be encouraged to take part in. For Application engineers and R&D Devs to do sabbaticals, on loan, to companies would build good relationships in the industry and ensure tight cohesion and understanding between the developers of LabVIEW and the customers' that use LabVIEW. There is nothing like a dose of ones own medicine to encourage improving the taste.

A quart of oil? Robot confirmed.