Page 1 of 2

CAN Address Conflict with Prior Version Keypads

PostPosted: Mon Jan 25, 2016 6:12 am
by Herrubermensch
I have wired into my setup two of the prior versions of the keypads that have pre-set CAN addresses for both the buttons and the LEDs. Unfortunately, these are the same pre-set addresses used by my M190 for transmitting various channels from the M190 that I need, resulting in a conflict on the CAN bus. I see only two solutions:

1. Send the old keypads into Motec for reprogramming and sell the converter box that changes the CAN bus rate; or

2. Change the pre-set addresses for the M190 in M1 Build.

The problem with the former is it requires a complete rewiring of my keypads and primary CAN bus, costs money, and renders the converter box useless. The problem with the latter is that the July 2015 version of the GPR package I am running is not available in the form of an M1 Build project and, thus, the package code cannot currently be modified to suit.

Can anyone divine a tertium quid or am I saddled with the foregoing alternatives?

--Peter

Re: CAN Address Conflict with Prior Version Keypads

PostPosted: Mon Jan 25, 2016 6:30 am
by Herrubermensch
Here is one thought, though I'm a little dubious of it for some reason: Run keypads directly to the M190 on a separate CAN bus using the lower bus rate. Transmit values from the M190 to the PDMs for control. Essentially, use the M190 as a hub for disseminating messages from the keypads because it has user selectable bus rates for each CAN bus. Thoughts?

--Peter

Re: CAN Address Conflict with Prior Version Keypads

PostPosted: Mon Jan 25, 2016 5:10 pm
by David Ferguson
Would it be possible to re-program the converter boxes to alter the addresses as well as the baud rate? I know I've used a CAN bridge to do something similar when the OEM had address conflicts with the built-in dedicated addresses for an SDL. I was able to pass through the OEM messages and cause them to appear with a different address.

Re: CAN Address Conflict with Prior Version Keypads

PostPosted: Mon Jan 25, 2016 5:33 pm
by Herrubermensch
David Ferguson wrote:Would it be possible to re-program the converter boxes to alter the addresses as well as the baud rate? I know I've used a CAN bridge to do something similar when the OEM had address conflicts with the built-in dedicated addresses for an SDL. I was able to pass through the OEM messages and cause them to appear with a different address.


Thanks. That's actually what I meant by Option 1, viz., reprogramming both the addresses in the units and the baud rate. But I wonder if Motec can reprogram the addresses without changing the baud rate? That way, the wiring stays the same and I make use of the gateway, but there is no conflict in the CAN bus addresses. Or if Motec would just release the GPR package in M1Build form, then I could simply change the addresses in the project and re-compile. But I don't have any idea when that is going to happen.

--Peter

EDIT: I'm sorry, I misread your post! Your idea was to reprogram the GATEWAY/baud rate converter to change the addresses from that point. No rewiring required, just a reprogramming of the gateway. That would be a very clean resolution. Thanks.

Re: CAN Address Conflict with Prior Version Keypads

PostPosted: Tue Jan 26, 2016 3:03 am
by tepid1
Herrubermensch wrote:
David Ferguson wrote:Would it be possible to re-program the converter boxes to alter the addresses as well as the baud rate? I know I've used a CAN bridge to do something similar when the OEM had address conflicts with the built-in dedicated addresses for an SDL. I was able to pass through the OEM messages and cause them to appear with a different address.


Thanks. That's actually what I meant by Option 1, viz., reprogramming both the addresses in the units and the baud rate. But I wonder if Motec can reprogram the addresses without changing the baud rate? That way, the wiring stays the same and I make use of the gateway, but there is no conflict in the CAN bus addresses. Or if Motec would just release the GPR package in M1Build form, then I could simply change the addresses in the project and re-compile. But I don't have any idea when that is going to happen.

--Peter


I'm told that 1.04 project has built in keypad support, but it's still in beta as we speak. It'll cost about $100 USD to upgrade and when it's released should fix your issues. I plan on upgrading as well when it's final.

Re: CAN Address Conflict with Prior Version Keypads

PostPosted: Tue Jan 26, 2016 3:17 am
by Herrubermensch
tepid1 wrote:
I'm told that 1.04 project has built in keypad support, but it's still in beta as we speak. It'll cost about $100 USD to upgrade and when it's released should fix your issues. I plan on upgrading as well when it's final.


Good to know! I'd be happy if I could just get my hands on an uncompiled version of the July 2015 GPR package!

--Peter

Re: CAN Address Conflict with Prior Version Keypads

PostPosted: Tue Jan 26, 2016 8:00 pm
by tepid1
Herrubermensch wrote:
Good to know! I'd be happy if I could just get my hands on an uncompiled version of the July 2015 GPR package!

--Peter


I agree. Too bad you can't decompile what's out there.

Re: CAN Address Conflict with Prior Version Keypads

PostPosted: Thu Jan 28, 2016 9:58 am
by Stephen Dean
Hi,

There will not be support of the Keypads through M1 Build/Tune in the foreseeable future.

Re: CAN Address Conflict with Prior Version Keypads

PostPosted: Thu Jan 28, 2016 10:00 am
by Stephen Dean
If you have a 1.4 Build license, the GPR July 2015 package is available. It is currently by email request only, but this should change shortly.

Re: CAN Address Conflict with Prior Version Keypads

PostPosted: Thu Jan 28, 2016 3:45 pm
by Herrubermensch
SDean wrote:If you have a 1.4 Build license, the GPR July 2015 package is available. It is currently by email request only, but this should change shortly.


Thanks, Stephen. I have access to a development license, and through that have 1.3 Build. How do I go about getting 1.4 Build and the uncompiled version of the GPR July 2015? I take it that 1.4 Build is not going to be made available for download as the prior versions?

--Peter