IMAQ error upon code deploy

We are getting the following error when trying to deploy code:

InfoNI_Vision_Development_Module.lvlib:IMAQ Get Calibration Info loaded with errors on the target and was closed.rrect function name.

At that point the code stops deploying.

If we remove the vision assistant-created VI (which uses the caliper tool) the code will deploy – but we need that tool to take measurements on the image!

Any help/ideas would be appreciated.

You must be using an 8 slot cRIO.

Since the 8 slot has half the memory, and since the vision module has grown substantially in recent releases, the imaging tool installs a simplified version on the 8 slot. The features that were removed were QR codes, meter reading, OCR, and other instrumentation and inspection features. Another beefy feature that we thought was not needed was the calibration. Can you see a way to do the measurement without calibration?

Greg McKaskle

Perhaps… We’re not strong programmers here on 1551 – that is to say, we’re better than we ever have been, but still not that great. We’re a rural team in a town without so much as a stoplight, 20 miles from a movie theater or Walmart or Lowes (and 30 from a Home Depot)… The only major businesses in the town are wineries, and there are no technical companies of any kind. As awesome as B+L has been in transforming our team into something better, the sixty mile commute has proved quite the impediment when it comes to mentorship. Programming mentorship is our Achilles’ heel, and while that must be my fault as lead mentor I seem to have no solution, and no head for it whatsoever. Thus, I’ve turned to Chief Delphi.

I finally have a group of enthusiastic students who want to learn, but don’t really have anyone to teach them. I’m impressed with what they’ve done so far, truly, but there are some hurdles here that seem to be beyond us. We’re in week four and have yet to get any data whatsoever out of the camera. To find out only now that there are backward-compatibility issues is discouraging to say the least – now we don’t even know what potential tools we actually have at our disposal. (Is there documentation detailing which features are not backwards-compatible that we missed somewhere? If not, how do we find out what tools we actually have out our disposal?)

That said, we’re trying to create a program that can find the middle of the blob so that we can try to implement our gyro code to turn that number of degrees, and this error has shut us down from being able to do any implementation at all and we can’t seem to find a way around it – not through lack of trying, but through lack of know-how to the extent that we don’t know how to even deploy code that even kind of works. We do this, and the code just fails. We’re at a loss.

I know you don’t like to give answers, Greg, but if you could throw us a bit of a bone here, we’d chew it to the best of our ability. This is something the kids literally know more about than I do, and I know more about it than the other adults helping the team – and the kids are stuck.

I sent a PM and email about how I can help. I can’t say where or even if the deleted calls are documented. The size increase was quite the surprise to us, and we had no choice but to upgrade, so we gave guidance to the vision team and they were nice enough to lighten the load for us.

My initial guess is that the dependency on calibration is due to using the more advanced, and presumably more expensive edge and measurement features. It may also be as simple as deleting some of the subVIs incorporated by the code generator.

I’m pretty sure we can work with this. I’m glad to lend a hand.

As for not giving answers – you can’t give what you don’t have …

Greg McKaskle