Jordan Kuehn

If this is your first foray into contracting, I highly recommend quoting on a time and expenses basis and providing a preliminary project plan with deliverables and milestones for them to sign off. Fixed price quoting is very dangerous for the inexperienced.

Definitely pursue a time and materials basis like ShaunR outlined.  Make sure to have clear milestones with time and cost estimates (often our first milestone is purchasing all of the hardware) and then not only get a sign-off, but try to negotiate so that you get paid after each milestone.  This serves two purposes, it helps keep you from fronting too much time or money, and secondly it is a very firm indicator that they agree that you have accomplished that milestone to their satisfaction (deliverable and actual cost).  If you run into trouble down the road (total # hours differs too much from the estimate for example) you can point to that sign-off and payment as proof that you and the customer both agreed to progress on the project after that point.

That being said, don't make milestones too small.  Depending on the size and scope of the project you might look at 20-80 hours of work.  You don't want to be spending a ton of time writing invoices and making them cut checks.

Thank you both for your fast response.

 

So basically the cRIO is not as easy to use while troubleshooting code... Does it take long to recompile/download the code to the cRIO's FPGA?

 

The cRIO-9064 that I am thinking of using, is a linux system. Can I use a host windows based PC to write the code and download it to the cRIO? Will it work?

Even simple FPGA code can take quite a lot of time to compile.  There are various strategies for maximizing each compile, and minimizing the compile time.

You can use a Windows PC to program all the cRIOs.  If you can use the scan engine, you can get a simple to moderate level system working without too much pain.  Adding the FPGA can add significant development time, especially if you have never programmed one before.

Here is the NI development guide that is a good resource as you have some more detailed questions.  http://www.ni.com/compactriodevguide/

I was about to comment with the same thing about FTP not being enabled. I can't confirm the exact year, but I think fairly recently the FTP server is not even installed by default.

So. Who is using a VPN on their Android or iOS to connect to their LabVIEW software?

That seems to be a question that would produce limited replies without the VPN caveat.

In a similar application to the off-shore oil well (fracking happens in very remote areas on land) we've used the GSM c-series module from SEA and other 3rd party DIN rail mount modems (MOXA) via a VPN hosted by the customer's IT department.  In addition to providing security and locking all other access down, the VPN gives us the ability to access the cRIO as if it were on the network and update software and such beyond just communicating via whatever protocol you've defined.

Aside from that, most of our applications exist in a separate factory floor LAN with no internet access.  That typically leaves us only concerned about locking the operator out of screwing with the system.

Link to the original example?

I too have done different things to better handle this kind of scenario.

 

Recently my interest has beek piqued by the possibility of using callback VIs for registering the Events rather than using the Event structure itself.  The advantage of this?  You can split the handling of the events among different levels of an object inheritance chain.  This method couples well with the command pattern for the receiving end.

 

Advantages: Essentially allows us to split up individual frames of the Event structure into individual (boiler-plate) VIs.

Disadvantages: Knowing somehow that the events are being handled somewhere and that the callback VIs themselves run int he root thread.

I can see the benefit to this, but callback VIs seem to obfuscate the code greatly to me, as you mention in your disadvantages list.

I was very skeptical when I first heard about those channel wires for the first time last March. After checking it out and reading this thread, I am still of the opinion that those wires would not help me or my team program better applications nor to program faster. As others pointed out, these do not offer any benefit in applications where VIs are dynamically launched which is the main reason I need to acquire the same reference multiple time in the first place (or use FGV, DVR, ...). Otherwise, I can acquire the Queue Ref or the User Event outside of parallel loops and respect the dataflow paradigm by passing the reference.  Anyhow, I am very curious to see what others might do with them.

While perhaps not relevant for your applications, I am still quite intrigued by the loosely alluded to cross-platform nature of these "wires".  If communication across platforms was as easy (and much safer than) using local variables I see a great benefit.  One big hurdle with cRIO programming comes about when a host computer is needed.  Some of the new platforms mitigate this need, but don't eliminate it.  If I can run a (LV) wire from a cRIO to a host machine without doing any configuration and have a loss-less transfer mechanism implemented I would be quite happy. Sure I can do the same thing with streams (or any of the raw TCP communication methods), but they can be clumsy and need to be wrapped with auto-connect logic to handle real world situations.  We use a high level language for many reasons, but abstraction is near the top of the list.

Don't we already have that with shared variables?

Shared variables aren't loss-less unless you have some magic I don't know about.  This seems to be a combination of NSVs and Network Streams without the additional configuration.

I understand their enthusiasm. I just think its the wrong aspect view. Wires have a definite meaning in the diagram., but what would they mean in the VI hierarchy?

To summarize, all the complaints I'm seeing are related to the representation on the BD.  Is that accurate?  

To me this seems like an incredible concept if done correctly.  Essentially a loss-less local variable that can communicate cross-platform from what I've gathered.  

As a final note, I think this subject deserves its own thread and this one can return back to highlighting the new features in 2015.  Though it might be a pretty short thread then... 

Thanks! 

Fab,

This looks really cool, I look forward to digging into it.  I haven't looked through all of the sessions next week, any chance you will be presenting it during one?

In 2014 the Stacked Sequence structure was removed from the palette, it is still supported just maybe close to being deprecated.

Side note:  I did not know this and reading this made me very very happy.

No problem.  I think that the Database Connectivity Toolkit should include a primer on ODBC that's easily accessible.  This same issue drove me crazy several years back.

http://digital.ni.com/public.nsf/allkb/E7984C0DA0F0E65086257694005B4CB7

If you insist, try Ctrl+Shift+N.

I've used these tools in the past to generate pie charts showing how much code in a project comes from OpenG, or vi.lib or is written from scratch.

That's an interesting thing to observe.  I'm not entirely certain exactly what that would mean about code I've produced for a customer, but I might look into this.  I think it may describe a great deal about the type of application.  I could see creating similar amounts of code for two different applications and producing very different results according to this metric.  

However, I want to make it so that the when the user presses the stop button, it will reset all the boolean switches to off (false).

 

Thank you guys for your answers,

 

After moving my stop, clear, and error daq blocks to outside the loop, the program now is able to switch on and off in about a second. 

 

I have been told using daq assistant is a very bad idea from other people. They tell me they always get errors and using daq accomplishes the same task as using daq assistant but more efficiently (I'm probably not using daq correctly so using daq assistant might be better). So, anyways I really want to learn efficient use of daq.

When starting out with simple tasks, get a task to work with the assistant.  Then copy it and open the front panel to convert it to a VI and poke around in the Block Diagram.  Basically ready-made example code for your simple application which will help you understand how to make more complex operations.

DataFlow 6.0.4

The previous link seems to do just that, it measures the time it takes for a loop to iterate.  But in most situations I'd recommend instead of trying to capture each frame as it comes in, tell it to acquire at 30FPS but then ask to read the frames remaining in the buffer.  This way if your loop rate is 200ms that's fine, you'll still get all the frames.  There are examples shipped with IMAQ that demonstrate both methods, and even shipped examples to calculate the actual FPS and time between iterations.

As usual hooovahh is more eloquent than me.  Check out "find examples..." under the help menu for some of the referenced content.  If you are looking for a quick and dirty FPS calculation my link will do just fine though.

You could also buy him some reading glasses to see things clearly at full resolution and 100%. 

I take an issue with that n**i word.   If someone comes to you and tells you your application doesn't run, you would also try to educate him that there is a lot more information needed in order for you to mean something for him, wouldn't you? In this case it is not even software I wrote so how would we have been able to even guess from the first two posts of the OP that GPIB might be involved? Nor did he provide any information about his application other than that it caused a specific error number. Posting in OpenG made me actually guess at first it may be related to some OpenG toolkit function, otherwise  I had left the post entirely alone in the first place.

My apologies.  Replace it with "overbearing rule enforcers".

I agree more information is needed and the subVI is essential to answering the question.  I just noticed a lot of hostility that seems out of place.

By the way: You posted in the wrong forum too. This seems to have nothing to do with OpenG functionality at all, so should have been posted in one of the more general forums.

As to where to post, I notified a moderator and they moved the thread into the General area, where you should have posted it in the first place.

Please don't post pictures.  Would you take a picture of notepad and post it on a text based language forum?

As to posting a photograph of a screen shot, well, posting the actual VI AND subVI would have taken less work for you and would be about 100 times more useful to be able to see how the VI that causes the error is built up. 

No need to gang up on the guy or be rude.  Forum nazis are almost as annoying as n00bs.

I'm interpreting that you want to measure how long your loop takes to iterate.  See the link below for a simple method for this.  Let us know if you are looking to control the timing of the loop or something else.

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