Konnect randomly disconnects

[gnrules]

Hi everyone,
in a machine that we recently installed, we added a Konnect board to handle a set of additional I/O.
It is connected to Klfop+Kanalog set with a shielded cable (0.8m long). the last part of cable is separated and connected to IDC for abnout 30mm and then to Konnect connector.

It happens randomly that we receive the "COMM ERROR Signature not A5" after which Konnect is not operative any more and requires running the initialization sequence again to come alive.

I have two questions: can I detect in code the error and force the initialize again? (just to have a quick fix)
I found this:
viewtopic.php?f=6&t=1583&p=6043&hilit=Konnect#p6043
but it is not clear what the suggested function do; I suppose Idle mean "not connected" while "serviced" means connected and operative. Is it correct?

looking in the distance what can I do to avoid this error? we already have a shielded cable (shileld connected only on one side), but it is clearly not enough; is there any measure w can do to understand the problem.

Thank you

Giancarlo

[gnrules]

Sorry i forgot to mention the exact error is:
"COMM ERROR Aux1 B7 (signature not A5)"

while konnect is initiaized with:

Code: Select all

InitAux();
AddKonnect(0,&VirtualBits,VirtualBitsEx);

[TomKerekes]

Hi Giancarlo,

Yes ServiceAux is a function pointer that points to a function to perform the next step in the communication sequence. If an error occurs communication is terminated and the pointer then points to an idle function.

What Version of software are you using. Some older Versions had some Konnect timing issues with certain configurations.

Receiving 0xB7 has 2 bits different than 0xA5. Bits 0 and 4. You might scope those bits for anything unusual.

0.8m is somewhat long. Is that required? What is the shield connected to? Probably best would be KFLOP GND on the KFLOP end only. Maybe post a photo of your wiring.

Are you using any of the power terminals or GND on Konnect?

[gnrules]

Hi Tom,
thank you for the quick response.
the ac tual length is a bit less something like 65 cm... it is required by the routing. we could shorten it but not too much. I think we can go down to about 50cm but not less.

the cable shield is connected to a chassis where kflop and kanalog are contained, and it is on the main ground plane of the electrical cabinet.
the cabinet has a DB15HD on the wall directly connected to kflop on the inside.
The grounding route is a bit complicated because we use analog signals to command servo drives and the analog ground is connected to general ground. so 24V GND and any other ground on the main plate. this effectively vanicsh any possibility to isolate kflop from the rest of the grounds.
Anyway we use last version (5.4.1) and no power supply is drawn from konnect.

When you say we can scope for bits 0 and 4 you mean the first 8 bit from JP connector on kflop?

In themeantime I will insert in our watchdog routine a check for disconnection and try to reconnect on the fly.
Do we need to call also InitAux for this scope or we can just call AddKonnect (Assuming InitAux was already call once)?

Thank you

Giancarlo

[TomKerekes]

Hi Giancarlo,

I don't entirely follow the grounding. I think the 24V circuitry should be isolated from the KFLOP GND,

I consider earth/chassis ground to be noisy so I wouldn't connect it to the shield around cables with signals.

When you say we can scope for bits 0 and 4 you mean the first 8 bit from JP connector on kflop?

Yes

See this cnczone thread which includes a document on the protocol.

In themeantime I will insert in our watchdog routine a check for disconnection and try to reconnect on the fly.
Do we need to call also InitAux for this scope or we can just call AddKonnect (Assuming InitAux was already call once)?

It would be best to call InitAux first even if possibly not necessary.

[gnrules]

Hi Tom,
yes, probably my explanation was not very clear.
In principle we try to separate 24V gnd from Kflop GND and keep any I/O optoisolated.
The actual problem is that our servo-drives connect the analog ground to their 24V gnd.
Thus meaning that kflop gnd (in common with analog output gnd) is connected to 24Vdc gnd and this is out of our control.
Moreover any voltage source above 18V mut have gnd connected to earth (as per norm requirement in Italy) so we have no choice about that.

Can you suggest a quick and effective method to isolate analog outputs gnd? If so we can separate kflop gnd form any other possible noise source (that was my original aim).

btw I put a konnect reset and reconnection in a watchdog routine in order to recover from any disconnection. I'll let you know how it goes.
THank you

best regards

Giancarlo

[gnrules]

well, as expected it works. the board reconnects, but the current status of the bits is wiped out during reconnects.
So the machine triggers a n error. At least it is not blocked in a floating state.

We definitely have to solve this disconnection problem. during the last errros the value of the signature was repeatedly 0.
I double checked if anyne access JP6 pins but it is not the case.

Any sugggestion on a measurement (possibly with scope) to better understand th problem source?

Thank you in advance

G.

[TomKerekes]

In principle we try to separate 24V gnd from Kflop GND and keep any I/O optoisolated.
The actual problem is that our servo-drives connect the analog ground to their 24V gnd.
Thus meaning that kflop gnd (in common with analog output gnd) is connected to 24Vdc gnd and this is out of our control.

I think the 24V wiring should be isolated from KFLOP's GND even if it requires an additional separate 24V supply for your amplifiers.

Moreover any voltage source above 18V mut have gnd connected to earth (as per norm requirement in Italy) so we have no choice about that.

Its reasonable to have the 24V circuitry with an earth GND connection but all that should be isolated from KFLOP's 5V GND.

the current status of the bits is wiped out during reconnects.
So the machine triggers a n error. At least it is not blocked in a floating state.

Are you referring to the inputs or outputs? I think the outputs, which are virtual bits, should persist. But they may glitch during the corrupted transmission. The inputs may also be invalid temporarily by the corrupted transmission but should correct after the next successful transmission within ~1ms. But yes the root cause should be addressed.

Any sugggestion on a measurement (possibly with scope) to better understand th problem source?

Yes with a scope you should be able to see exactly what is happening especially if the scope has a good amount of memory. The code that detects it going idle could pulse an output to trigger the scope and then you could see what happened just beforehand. You might scope START, CLK, and Bit0.

[gnrules]

I think the 24V wiring should be isolated from KFLOP's GND even if it requires an additional separate 24V supply for your amplifiers.

Sorry Tom, not sure to understand: our servo amplifiers tie all the GND signals togheter. Kflop + Kanalog share the same GND for both I/O and Analog outputs. Even If I use a separate 24V source just for the amplifiers how can I keep them separated? when I connect analog outputs from Kanalog to Servos the connection is inside the servo itself.
Is something that I'm missing?

The inputs may also be invalid temporarily by the corrupted transmission but should correct after the next successful transmission within ~1ms.

Good to know, maybe I just need to add a little delay in order to recover and not to trigger anything because of disconnetction.

I'll try this first and then I'll go with the scope looking for the disturbance source.
Thank you very much

G.

[TomKerekes]

Sorry Tom, not sure to understand: our servo amplifiers tie all the GND signals togheter. Kflop + Kanalog share the same GND for both I/O and Analog outputs. Even If I use a separate 24V source just for the amplifiers how can I keep them separated? when I connect analog outputs from Kanalog to Servos the connection is inside the servo itself.
Is something that I'm missing?

Maybe you could post a link to the Servo Drive manual. Is it creating 24V itself? Does it require 24V enables or such that have a common GND with analog GND? But regardless I'm guessing you have 24V signals for things like limit switches, relays, and such running all over the machine. That could be all operated from a separate, isolated, 24V supply.

Good to know, maybe I just need to add a little delay in order to recover and not to trigger anything because of disconnetction.

One trick might be to read the Konnect inputs into a 2nd set of VirtualBits. Then in a forever loop every 2ms make a copy of these bits. Then after another 2ms if there has not been an error the copy is known to have been from a good transmission so then copy these to the VirtualBits you use.

Maybe this (untested)

Code: Select all

#include "KMotionDef.h"

typedef void AUX_FUNCTION(void);
extern AUX_FUNCTION *ServiceAux;
void Idle(void);

int main()
{
    double T, NextTime = 0;
    int InputBits, CopyBits;
    BOOL CopyValid = FALSE;

    InitAux();
    AddKonnect(0, &VirtualBits, &InputBits); // read inputs to dummy bits

    for (;;)
    {
        T = Time_sec(); // get current Time_sec

        if (T > NextTime) // time to update?
        {
            NextTime = T + 0.002; // update again in 2ms

            if (ServiceAux == Idle) // error?
            {
                InitAux();                               // restart Konnect
                AddKonnect(0, &VirtualBits, &InputBits); // read inputs to dummy bits
                CopyValid = FALSE;
            }
            else // no error
            {
                if (CopyValid)
                    VirtualBitsEx[0] = CopyBits; // copy valid bits to the bits we use.

                CopyBits = InputBits; // save this transmission
                CopyValid = TRUE;
            }
        }
    }

    return 0;
}