Cannot log into NI1742 after it is set to automated inspection

[Diljay]

Hello

I have in my possession a NI1742 Smart Camera.  Once I set the camera to full automation, I cannot log back into the camera through the Ethernet port. 

The steps I have done:

Go to the Target Tab --> Target Options --> Startup --> Start Inspection when launched

The only way I was able to disable the automated inspection is by resetting the camera.  However this deletes the uploaded program. 

I have the standard manual.  Is there another manual that I'm not reading?

Thanks

[Paul_M.]

Hi Diljay,

It sounds like the inspections that is started on launch of the 1742 may be using up all the system resources and therefore is making it appear that you can't log back into the Smart Camera. Since the Smart Camera is a real time system, it's going to give priority to the deterministic functions that are being called, i.e. the inspection that you are running rather than reserving resources for non-deterministic network functions.

Something that you can do is monitor the CPU usage using the Distributed System Manager from your host PC. When you open the Distributed System Manager you should be able to find your 1742. Under the 1742 tree you should see NI_SystemState and then CPU Load. Under the CPU Load tree you should be able to select CPUs and view the CPU usage on the Smart Camera. If the usage is very high or nearly 100% this would explain your inability to connect to the Smart Camera when the inspection is running.

It's important in your inspection code to include wait times within inspection loops in order to free the processor up to handle any other tasks, such as network management.

Let me know if this helps.

Paul M

[Diljay]

Thank you Paul. I will try that and keep you updated.

[Diljay]

Ok I have tried to access the distributed system manager but I am getting this error.

I have tried to search for fixes that involve updating the microsoft framework but it still does not work

Here is the error I am receiving.

[Paul_M.]

Hi Diljay,

Does this error occur every time you try to open the Distributed System Manager? Or only when when you have the Vision Builder for Automated Inspection (VBAI) running on the Smart Camera? 

In order to get the Distributed System Manager working on the Smart Camera we may have to install the System State Publisher to the target. This process is explained in this knowledgebase article.

Also, we can monitor the memory usage of this inspection in the Configuration View by selecting Target » Target Information.

Paul M

[Diljay]

I've found the answer!

In order for one to log back into the camera via ethernet after is has been set to automated inspection,

you have to add a small delay in the algorithm.  By doing so, this will give a window of time for the user to

turn off the inspection. 

[Reneance]

Hi,

I haver similar problem.  I start the inspection with only 15MB and dropped to 7MB later on a message low memory.  I put delays on states that loop (about 50msec) but still the same.  I made a  simple program but memory left still at 20MB out of the 120MB+.  Where shall I put the delay? As a single state between states?

Also I tried running a labview VI using run VI.  The VI is supposed to popup a window but its not happening.  I used front panel open / close also not working.   I talked with local tech in Philippines and dont have clear solution.  I needed popup windows in my application.  Managed to go around it by using tab control for the messages but this made the program big.

Im using 1742.

thanks

bobot pachico

[NateBraska]

Hi Bobot Pachico,

With memory, the waits will not help like they would with processor usage. With the previous case, having the processor running constantly was preventing less prioritized processes from running. Your case sounds like there is not enough system memory to run this application.

So it seems like this issue may be a bit different. I would suggest you try to see if you can limit the amount of times your capture images throughout a single iteration of our code; each capture makes several copies of the image and takes up more memory.

Are you having similar problems in no being able to log into your automated inspection like the original poster?

Best Regards,

Nathan B

Applications Engineer

National Instruments

[Reneance]

Hi,

thx for the reply.

Yes I have a similar problem as the previous poster.  when i do a memory check att configuration, the memory starts to dwindle.  So i started reducing the program size.

Actually there is only 1 acquire and then 1bout 10 transistions based on a modbus input (4 bit status input).   the 10 transistions are for the different patterns to check based on the input.  if an inspection fails then I have to show a pop up window which is actually a tab in the interface that I selected.

I made another simple application and the memory did not improve much.  its about 20 mb remaining. 

I attached my vbai file for you check.

the 5x5 is the scaled down version while the other one is the full one.

Also, when I run a vi that requires a popup window, it doesnt appear when ran on target.  at simulation it is running.  I did the procedure of building the vi to llb and tansfer via ftp to the camera.  when ran on target, the application just hang because an input is required.

thx

bobot

[Brad]

You cannot have a popup window work in a Run LV step when run on a target. The VI is actually run on the target, so you won't see the VI on your host machine. This is why the User Input step is not available for RT targets. I like your tab control to show the different states and achieve a popup like experience. One thing that could save some memory is to remove all the Calculator steps you have before each Update Custom UI step. It looks like you are trying to set the tab control in this step (i.e. setting a property node to a constant), but it doesn't actually do anything (except take up memory and processor time) because the Set Custom UI step is what will actually change the tab control value. So deleting all the unnecessary steps should free up some memory and run faster.

To help with the target not being responsive when running in inspection mode, you should put a delay any place where the inspection could loop repeatedly very quickly. It looks like you have delays in lots of places, and I'm not sure all of them are needed, but at least you give plenty of time for target to respond to outside connection requests.

Another idea instead of trying to implement a bunch of user interaction in the UI running on the target is to make a UI on your host machine and use the new VBAI API to control just inspection that runs on the target. This way the target doesn't need to handle all the login/password/user interaction that is probably more natural to handle in Windows VI or C app where you can have popup dialogs, and based on the UI interaction on the host side, you use the API to tell the target to run an iteration of the inspection and you can set shared global variables before hand so when the target does run, it can use values set from the host side in the inspection. I realize this is a big change from the inspection you have already, but I think it could have a lot of advantages:

- VBAI focuses on what it does best...automated visual inspection and leaves UI interaction/admin logging in control to a programming languages that is easier to accomplish this (i.e.LabVIEW).

- Makes your inspection smaller so it takes up less memory and you don't have to worry about running out of memory as easily.

- Makes it easy for your application to grow and include multiple smart cameras/targets all controlled with one UI.

- Makes you inspection a lot easier to read so not so much of the state diagram has to deal with user access/password types of interaction.

Some of the down sides include:

- reworking inspection to seperate UI interaction and username/password log in code from visual inspection

- need to synchronize updating variables from host to target with UI interaction/logging in...shared variables work pretty well, but they are not meant to be deterministic or synchronous (i.e. no gaurntee that a variable you set first will be updated first on target, so even though you set params before you set a flag to start inspection, the start inspection flag may be updated on the target before the params are). There is a Flush Shared Variable VI that can help avoid this problem though, but just wanted to make sure you knew this was something to look out for and handle by using the Flush Variable VI.

Anyway, something to think about. Thanks for including your inspection, very helpful to see how you're using VBAI.

Thanks,

Brad