Hi Everyone
I am currently evaluating this device in view of a future upgrade to an existing system by using Roboguide and simple push button and led (to act as a sensor and output connected to the Balluff).
Roboguide which has the relevant options set and also the ethernet/ip rack/ports/instances have all been configured and communication is all working fine and dandy.
Now I am unaware of any existing bugs within Roboguide or settings which may be the root cause of my problems, but Balluff are telling me what I am seeing is normal and what you are seeing in the attached video clip is expected.
Unfortunately, at this point I cannot connect to a live robot to eliminate Roboguide out of the loop, but Balluff are telling me this is normal...........
In the clip (from 00:24) looking at the TP IO monitoring when you look at the DI (left side) - You can see DI 121 is reflecting/mirroring the Output 121.
My fieldbus allocations are simply placed as DI start at 121 and DO start at 121.
So my initial plan was to have the push button on DI 121 and the Led on DO 121.
Initially the below program was using DI 121 as the push button not DI 122.
But when I did this, DO 121 failed to turn on.
So I then moved the DI to 122 as the below program, and then DO 121 then turned on and off with the push button.
But upon doing this, I discovered that DO 121 state was being reflected/mirror'd on DI 121 - even though I was not initiating it.
As far as the logic is concerned, it makes sense why DO 121 was not turning on with DI 121 due to this reflection/mirroring, so I'm not concerned about the BGLOGIC side of things as fundamentally I cannot do a simple DI x to the equivalent DO x signal exchange.
The code below is a simple BGLOGIC task that is in the video clip.
: !================================ ;
: ! Just a Logic Test ;
: !================================ ;
: IF (DI[122:Button Press]=ON) THEN ;
: DO[121:Press OK]=ON ;
: ELSE ;
: DO[121:Press OK]=OFF;
: ENDIF ;
What I can't get around is why 'any' DO I use with this module when triggering it with a DI, the equivalent DI reflects/mirrors the DO used.
Now Balluff are telling me this is normal for the device and it is correct - But I have serious doubts...........
So my underlying questions:
1. Has anyone used the above module (16 input/output module) with Roboguide or a live robot yet?
2. If yes, have you experienced this behaviour when a DO is being reflected/mirror'd to it's opposite DI.
3. Could this be a Roboguide issue, or a Fanuc issue in terms of a bug or setting I am missing - I would love this to be the case.
4. Am I really led to believe Balluff would sell a product that by design reflects/mirrors output states to the equivalent input.
Any comments, experiences or suggestions would be most welcomed.
P.S
I believe this is a fundamental issue, so I am not looking for any solution suggestions which 'masks', 'bypasses', 'circumvents' the problem with code.
But if you have a theory/setting that you think is causing this in the Fanuc, then I would be interested in trying out some suggestions.