Remote display for Interface Panel and iRVision

  • G'Day, all. I have a customer who wants a large external display added to their CRX robot. They want this display to show the Interface Panel (J741 option on the robot), and the most recent iRVision image, with the graphical results of the Find tools. This is just a display -- no controls. The "big screen" should show these displays regardless of what anyone's doing with the tablet pendant.


    Off the cuff, the simplest way to accomplish this seems (to me) to be to set up a small PC that just boots directly into a custom web browser that "pulls" the IFP and iRVision displays from the robot's internal web server. But I'm sure there are some complications there. For example, the IFP "web page" seems to auto-refresh (probably using JavaScript), but I've only ever used the iRVision web page for logging in to make configuration changes -- is it even possible to get a "status" page from iRVision? Especially when I have multiple different iRVision programs run at different times (this cell will run multiple types of part). And would the iRVision display auto-refresh, or would I have to hard-code my client browser to cyclically refresh the iRVision page?


    Alternatively, is there a better Fanuc option I could add to the robot that would make echoing these displays to an external device easier and more robust? The ideal solution would probably be to add an actual industrial HMI, but I doubt the budget will support that.


    I'm weak on Fanucs in general, so I'm open to any ideas from people with more experience in this area. The fact that the robot is a CRX might complicate things, but so far, what I've seen suggests that the CRX looks like a regular "yellow" robot insofar as these display and interface options are concerned.

  • iRvision has a runtime webpage that displays the last vision process image and result. Have you tried viewing that?

    I just found that, after making that post. It looks like what I want, except... on the test robot, it seems to be awfully unreliable. Every time it refreshes, it's a crapshoot whether it shows me the actual image, or some old historical image that shows the camera view from over an hour previous.


    This is a video of what the runtime webpage shows as the robot performs multiple vision runs back-to-back. I've tested, and I see the same sort of issue just using the "live camera view" in the setup page, and even sometimes when I just use the manual refresh button. So I don't think it's just the speed with which the robot is triggering the consecutive tests.


    https://photos.app.goo.gl/xHj9qzHyjaa26hxu5


    Running LRHandlingTool, Version 9.1

  • Have you set your runtime refresh higher than your vision process? Default is 100ms. You can set this in Vision Config.


    Keep in mind that runtime will bog down your vision process. It doesn't look like this will be an issue in your case, just an FYI. Logging images could be an alternative if that becomes an issue.

  • Have you set your runtime refresh higher than your vision process? Default is 100ms. You can set this in Vision Config.


    Keep in mind that runtime will bog down your vision process. It doesn't look like this will be an issue in your case, just an FYI. Logging images could be an alternative if that becomes an issue.

    I haven't touched the Runtime settings, so they should still be the default. I'll check, though, thanks.


    The robot I'm seeing this strange behavior on is not the robot I need to add the "permanent" Runtime display to -- it's just the robot I have on hand that has iRVision up and running, so I used it as a test case.


    What worries me most about this is that I'm getting the same "flicker" between current and "old" images even outside the Runtime display -- when I'm in the Config page and select "live video," for example, or if I hit "manual refresh" multiple times in a row.

  • I was recently working on an application where I saw what you were describing - unreliability in the vision runtime. The cause was my trigger interval was way lower that my vision processing time. It was with a iRPickTool conveyor that was triggering every 100 ms or so when my vision process was running at around 500 ms... there were vision 'over-runs'.


    After reviewing your video again, your processing time doubles as soon as it passes a good part - 80ms to 230 ms.. Is it possible you can:

    1. Simplify your vision process

    2. Increase your trigger interval time - at least to your highest processing time


    Assuming this is what is bogging down your runtime.


    After I made changes to the two items above, I saw night and day results in both the runtime and the overall application itself. The runtime went from updating every 1.5~ sec to about 100 ms.

  • I don't think I can simplify the vision tasks -- they're literally dirt-simple already. Just an image, and a simple Histogram tool (whose area of interest is limited to just one grid rectangle). My pass/fail is a simple eval on how many pixels are above 250 threshold. The only thing that might be driving the tasks to "go long" is that they have different exposure times, due to the large variance in illumination I have across the grid.


    I do see what you mean about the timing, though -- when I get a chance, I'll see what happens if I bump the Runtime refresh from 100 to something big, like 300 or 400.


    Hm... one of the oddities in this setup is that the TP program repeats each task until it either fails three times, or passes. I wonder if that's causing some of those huge timing variations? Maybe repeating the same VT just adds to the execution time, instead of starting the timer fresh?

  • So, I tried bumping the Runtime refresh to 500ms, tried turning Logging off in every VT, tried putting 1sec time delays between VT executions, and tried eliminating all repeat VT calls. No dice -- the Runtime display just keeps doing that.


    I should mention that the "flipping" iRVision Runtime display was on an LR Mate that I happened to have handy (before it shipped out to its final destination). I'll have to see if I have any issues like this with the CRX once it actually arrives.


    And regarding my question about the Interface Panel, from what Fanuc support says, it sounds like there is currently no official option to get a "remote" display of anything on the Tablet pendant -- if the CRX were using the iPendant instead, apparently all the "regular" approaches would work.

Advertising from our partners