SOWEGATS (Customer) asked a question.
Which command uses less network bandwith when reading/writing data to the input/output assemblies: Publish & Subscribe or Copy?
I am using Teknic ClearPath Servo Motors and ClearLink Step/Direction Motion Controllers.
Regarding the Teknic EDS File:
1) The Configuration Assembly imported and "formatted" just fine. I.E. It made a UDT(?) with labels on its own, correctly, with the proper labels for each memory location. These are all accessed from the "Edit Adapter" screen.
2) The Output and Input assemblies were both too big for automatic or manual setup of UDTs, because they are both bigger than 256 Bytes. Also, I could not modify the EDS, because it would have changed the index #s of the registers, and Teknic strongly advised against that. Howerver;
3) I was able to set up custom Memory Blocks (332 Bytes for the Output Assembly [named ROUTB] and 280 Bytes for the Input Assembly [named RINB]) and they are correctly indexed to the actual Tecknic Output and Input Assemblies, with no offset! 😊 E.G. For the Output Assembly, Teknic Documention shows Bytes 24-27 as the Move Distance Registers/Bytes... This corresponds EXACTLY to ROUTB24-ROUTB27, and I Publish or Copy values into those Registers as a Signed DWord; hence, my question at the top of this message.
4) Only real problem I have is that the Enable Bit for the motor is dropping out randomly, shutting down the motor, but re-establishing so quickly that I cannot catch with the PLC (apparently, faster than the BRX Scan Time, but long enough to shutdown the motor). Is there a network buffer that could be causing this? Or a network speed (200 packets/sec) - vs - PLC Scan Time issue?
Thanks and God Bless!
SOWEGATS
COPY vs. PUBLISH/SUBSCRIBE just affect the ladder scan (minimally). If everything is aligned, you can use COPY, which is faster. If you need to swap bytes or of a REAL (for example) is not lined up on a DWORD boundary (e.g. ROUTB6-9 is NOT DWORD aligned), you would have to use PUBLISH/SUBSCRIBE.
If there's no byte swapping and you are good with casts, you can just use COPY with raw bytes ROUTB6 into R42:UB0 count of 4 BYTEs. COPY is faster, but it only affects the PLC scan time, not the network EtherNet/IP polling behavior.
Thanks!
I am comfortable with casts and have been using them some in this program.
Any insight on why my enable bit is randomly dropping. Could that have anything to do with Publish -vs- Copy?
If you are writing to it improperly, then absolutely yes. I presume it is a bit. Is it part of a group of bits in a single byte? Or does the whole byte just represent a single bit? Or???
Any/all details you can provide about the various bits would be good.
I can send that bit as an individual bit [e.g. ROUTB48:0 (byte48:0)] or as part of a Velocity/Position command byte [e.g. Routb48 (byte48) = 9, for position move with motor enabled] - Teknic calls that the Motor Output Register (Class: 0x66, Instance: 1-4, Attribute ID: 6). For Motor0 It is bytes 48-51 in the Output Assembly (Instance 112).
I have tried sending only bits with Copy, bytes with Copy and bytes with Publish. The results are the same. The ClearLink Controller will follow the commands from the BRX Program and the motor will move/run as intended, but after a random period of time, the motor will suddenly stop, because it momentarily lost it's enable bit. 😟 I put a rung of code in the program to monitor that enable bit and to set a contact bit (e.g. C100) when the enable bit dropped out, but that rung is never triggered... the enable bit is being re-enabled faster than the BRX scan-time... but once the motor sees that bit disabled it stops and requires another command to restart it, which it will do. No Faults initiated... only the Alert that the Motion was cancelled because the enable bit was de-asserted.
Again, this happens randomly. It may happed after only a few seconds of running or it may not happen until after a few minutes (10-15 minutes).
The following is from Teknic's Documentation.
Bit# Value
0 Enable
1 Absolute Flag
2 Homing Move Flag
3 Load Position Move
4 Load Velocity Move
5 SW E-Stop
6 Clear Alerts
7 Clear Motor Faults
(8-31) Are reserved for future use. (According to Teknic, all of these bits are zero and do not need to be written, even though they are reserved in the Output Assembly.)
Many Thanks and God Bless!!
SOWEGATS
You mention an Enable bit in the device and the Enable bit in the PLC. You are saying that the Enable bit in the PLC stays ON. The best way to check that is at the bottom of scan, have an INC D99 being driven by a DELTA CONTACT ROUTB48:0 and that D99 does not go up whenever the machine becomes DISabled. D99 should go up whenever you explicitly want to ENABLE it and whenever you explicitly want to DISABLE it. D99 is NOT going up when you see this strange behavior. That is my question.
I am monitoring ROUTB48:0 as a Trailing-Edge One-Shot Contact to set bit C10. This should turn on C10 whenever bit ROUTB48:0 drops out, but it never gets triggered. I am running Stages, so I have this rung placed as the last rung before the initial stage (S0), so that it runs every scan.
That works. Very strange. You might need to post questions on the Teknik device.
Is there a feedback bit "IsEnabled" available via EIP? I guess you are able to monitor the actual Enable bit inside the actual motor somehow?
Could there be another "mode" that kicks it out of "enabled"??? An alarm condition (too fast, bad command)? Something related to the servo behavior itself, not EIP related.
I have no idea. I'm wondering about an Ethernet "buffer" and Network polling time -vs- PLC scan time conflict. I have talked extensively with Teknic. They say that one the enable bit is asserted there is nothing that should de-assert it, except for an intentional change by Implicit or Explicit command.
Also, it happens with Positional Moves as well as Velocity Moves. They will both eventually exhibit the "Motion Cancelled due to Enable Bit being de-asserted" behavior.
I also wrote an entirely different code block program running only a velocity command as a test. This program starts the motor and keeps it running at a specified velocity, until I intentionally stop it. But, if let it run long enough, it will eventually exhibit the same "Motion Cancelled due to Enable Bit being de-asserted" behavior.
How do you know the enable bit is actually changing in the device?
I just thought of this - is your trailing edge contact rung in $Main? Even better, $tBottomOfScan.