M1XEP disconnecting

mikefamig

Senior Member
This group has helped me a lot in installing my M1 so I like to share when I learn something new that I think may be helpful.
 
I have been tinkering with and adding to my system via ElkRP/xep for a week or so now with no malfunctions until this morning. Every time I would connect to the xep with ElkRP it would be fine for about thirty seconds and then disconnect from the xep with the message "control has disconnected".
 
 
Long story short..... after an hour of troubleshooting I remembered that last evening I installed a trial version of CQC to see what it looked like. I uninstalled CQC, rebooted and my ElkRP has been successfully connected for a half hour with no disconnect.
 
Hope this saves someone some time, Mike.
 
The Elk is supposed to send a message out when RP connects to it, to tell other things connected to back off while RP is connected, then send another when it exists to let us get back in. I'm not sure how the xep fits into this, or even what it is to be honest. I'm just wondering if something has changed wrt to how this scheme works. We have lots of Elk M1 customers, and haven't had any complaints on this front, so I'm assuming either the xep is something none of them use and it works differently than things have in the past, or there's something specific about your setup that is not being accounted for, or maybe some difference in a recent firmware upgrade or something like that.
 
Oh, doh, you mean the Ethernet to serial connector. Clearly lots of our customers use that, so there's got to be something else going on there. Are you connecting ElkRP via the secure port? I'm not sure if it's possible to do it via the unsecure port, but if so, you'd probably want to do RP via the secure one .
 
Yes the XEP is the ELK ethernet adapter that is connected through the serial port and the hardware is new and the software is all upgraded to the latest firmware. I am configured to use the secure port 2601 and static IP address. I even opened a new blank account, added the xep setup and connected and had the same disconnect problem.
 
I installed just the main CQC program and it was not yet configured. I ran it and it seemed to need some add-on or something to communicate with the elk but it was my first look at the software and I know nothing about configuring or using it. My guess is that it loads some service or some sort of driver at windows start that is polling the elk or communicating with it in some way that intefered with th RP software.
 
I even ran a long cat6 patch cable between the elk and the gateway.....same problem. As soon as I un installed CQC the problem disappeared.
 
Mike.
 
There's no way, unless you explicitly configured it to, that CQC is talking to the Elk in any way. It doesn't pre-load support for any devices at all. So it can't be anything to do with that.
 
Dean Roddey said:
There's no way, unless you explicitly configured it to, that CQC is talking to the Elk in any way. It doesn't pre-load support for any devices at all. So it can't be anything to do with that.
I never say never.
 
In this case it's not possible, trust me. CQC doesn't make random connections to things. It only connects to something if you load a driver to make it do so. So it would have to be something else besides that.
 
Are you sure you didn't somehow get the XEP on the same IP address as the computer or something like that?
 
The only thing otherwise that they could be fighting over is if RP opens a listening port to listen for connections and it happened to use one that one CQC's servers uses. The thirty second thing would be explained in that case by the RP program attempting for 30 seconds to open the listening port, then giving up.
 
Dean,
 
I know that plenty of users here and other utilize both CQC and Elk. Heck, maybe one day I will be... I mean, I do own a license ;-)  Anyhow, based on the previous comments about the XEP, what is the recommended (or usual) hardware connection between the M1 and CQC?
 
Dean Roddey said:
In this case it's not possible, trust me. CQC doesn't make random connections to things. It only connects to something if you load a driver to make it do so. So it would have to be something else besides that.
 
Are you sure you didn't somehow get the XEP on the same IP address as the computer or something like that?
 
The only thing otherwise that they could be fighting over is if RP opens a listening port to listen for connections and it happened to use one that one CQC's servers uses. The thirty second thing would be explained in that case by the RP program attempting for 30 seconds to open the listening port, then giving up.
 
I know nothing about CQC and only what I've learned about the Elk in the past couple of moinths so I'm not sure of anything. I have been troubleshooting pc's for years and it's hard for me to say that CQC is completely innocent ion this case. I'm just happy that I didn't lose more time troublesjooting it than I did.
 
Mike.
 
Plenty of folks use it either way. There may be different versions of it, but the one I have just puts an IP based box in front of the serial port. I.e. it's not any faster because it's still just going through the serial port. But, it does allow you to connect to it via IP (acting an IP to serial converter), and presumably it allows the Elk to indirectly send out IP based messages by sending commands to the XEP out the serial port. And it would also allow for multiple simultaneous connections to the Elk, i.e. the RP and CQC at the same time, which wouldn't otherwise be possible.
 
Plenty of folks use it either way. There may be different versions of it, but the one I have just puts an IP based box in front of the serial port. I.e. it's not any faster because it's still just going through the serial port. But, it does allow you to connect to it via IP (acting an IP to serial converter), and presumably it allows the Elk to indirectly send out IP based messages by sending commands to the XEP out the serial port. And it would also allow for multiple simultaneous connections to the Elk, i.e. the RP and CQC at the same time, which wouldn't otherwise be possible.
 
mikefamig said:
I know nothing about CQC and only what I've learned about the Elk in the past couple of moinths so I'm not sure of anything. I have been troubleshooting pc's for years and it's hard for me to say that CQC is completely innocent ion this case. I'm just happy that I didn't lose more time troublesjooting it than I did.
 
Mike.
 
One obvious way to test it would be to run RP from a machine that CQC isn't running on, while CQC is installed on another machine. If that works, then it can't be due to a conflict at the Elk itself. If the other machine where CQC is running still has the issue, it would prove that it's some sort of local conflict for resources, and I would be happy to help figure it out.
 
Dean Roddey said:
Plenty of folks use it either way. There may be different versions of it, but the one I have just puts an IP based box in front of the serial port. I.e. it's not any faster because it's still just going through the serial port. But, it does allow you to connect to it via IP (acting an IP to serial converter), and presumably it allows the Elk to indirectly send out IP based messages by sending commands to the XEP out the serial port. And it would also allow for multiple simultaneous connections to the Elk, i.e. the RP and CQC at the same time, which wouldn't otherwise be possible.
 
Ok, that's why I asked... the messages above where you weren't aware of what the XEP was concerned me to think that most people connected to CQC differently. I've had my Elk for over 2 years now, and any time I've ever initiated ElkRP for programming, it disconnects any thing else.
 
To further explain, if I have eKeypad open on my phone (connected to Elk) and then open ElkRP on my computer... it will interrupt the eKeypad session, and report such message.
 
I wasn't sure if people were connecting via an additional XSP (serial port) and communicating with CQC that way.
 
Back
Top