Trigger Commands don't appear to work on MXG and RS3?
#1
Trigger Commands don't appear to work on MXG and RS3?
Hello,
I'm having an issue where I can't seem to get any of the Trigger Commands to activate on my AIM MXG Gen 1 unit. I am fully up to date with all of the firmware and software versions, but when I set the RS3 and MXG to trigger a particular action e.g. trigger "next display page" when wheel speed goes above 50kmh, and then I force wheel speed above 50kmh via RS3, nothing happens on the dash.
Same thing if I try to get the dash to move to a Previous display page as well... nothing seems to happen when the conditions set are met
Same thing when it comes to activating a particular button... nothing sems to happen when the conditions set are met.
It is as if the "Trigger Commands" section of RS3 does not work at all.
Is there something I am missing with respect to how these Trigger Commands work in RS3 that I missed the memo on?
Thanks very much in advance for your time
I'm having an issue where I can't seem to get any of the Trigger Commands to activate on my AIM MXG Gen 1 unit. I am fully up to date with all of the firmware and software versions, but when I set the RS3 and MXG to trigger a particular action e.g. trigger "next display page" when wheel speed goes above 50kmh, and then I force wheel speed above 50kmh via RS3, nothing happens on the dash.
Same thing if I try to get the dash to move to a Previous display page as well... nothing seems to happen when the conditions set are met
Same thing when it comes to activating a particular button... nothing sems to happen when the conditions set are met.
It is as if the "Trigger Commands" section of RS3 does not work at all.
Is there something I am missing with respect to how these Trigger Commands work in RS3 that I missed the memo on?
Thanks very much in advance for your time
#2
Rennlist Hoonigan
which cost no drachmas
Lifetime Rennlist
Member
Rennlist
Site Sponsor
which cost no drachmas
Lifetime Rennlist
Member
Rennlist
Site Sponsor
Joined: Dec 2001
Posts: 12,741
Likes: 1,037
From: Manchester, NH
I'd have to see the config to see what is going on, but it should work. I don't have a Gen 1 device to try it out on. Make sure the < and > are correct as well.
#3
https://www.dropbox.com/s/u4aa25mhlv...1.zconfig?dl=0
Thanks for the response... The above link should give you a copy of my config. Hopefully you see something that I missed...
Thanks for the response... The above link should give you a copy of my config. Hopefully you see something that I missed...
#4
Looking at the configuration more, I'm also noticing that certain configurations that I make in the software (eg. to display certain parameters in certain colours) are not carried out. For example in the configuration above, I have it set up to display gear position in red. Yet, when I send the configuration to the dash, gear position is still displayed in white.
I also came across an interesting warning this morning while making a few configuration changes - ".*config file name here* has a number of Math Channels or Alarms that exceed the maximum admitted. Please delete"1" elements to avoid missing data.......Do you want to transmit anyway?"
Not sure if I'm running into a bug or some limits as far as how many channels the MXG can deal with here.
I also came across an interesting warning this morning while making a few configuration changes - ".*config file name here* has a number of Math Channels or Alarms that exceed the maximum admitted. Please delete"1" elements to avoid missing data.......Do you want to transmit anyway?"
Not sure if I'm running into a bug or some limits as far as how many channels the MXG can deal with here.
#5
Rennlist
Basic Site Sponsor
Basic Site Sponsor
Joined: Jun 2008
Posts: 19,273
Likes: 3,473
From: Durham, NC and Virginia International Raceway
In the AiM Users Group on Facebook, a fellow was having the same issue with the specific triggers not being “accepted” by the config.
AiM Sports National Training Manager Roger Caddell showed how the order in which they are entered makes the difference in making this work.
The original query was: Looking for a little help with display measures...
Getting very inconsistent results with using display measures to change color of text data displayed on MXS 1.0 dash. For example trying to have RPM value change color to match the shift lights. First tried setting 'above 6200 = white' 'above 6800 = yellow' 'above 7200 = red' to no avail. Then thought maybe range triggers would work better and tried above > below variables for each of the ranges '6200>6799 = white on' '6799>6200' white on, '6800-7199 = yellow on' '7199>6800 = yellow on' and '7200-8000 = red on' '8000>7200 = red on' All of these resulted in RPM data on dash not change color at all.
Also tried similar data with oil and water temps which I had slightly more success with but not perfect. Set up range above/below and below/above for each data type same fashion as RPM above. The oil temp data seemed to follow this logic and change color depending on which range it was in. Water temp just stayed blue (coldest range) no matter what.
Maybe only certain data types can have the data change color depending on ranges?”
Roger’s answer was: Hi Ryan Vosburg, You are close :-)
I have attached a screen capture that shows that the order that you have the alarms 'stacked' matters. Think of it as layering and the 1st (lower temp colors in my example for water temp) must be lower in the list. In my example
1) The water temp text color is blue when less than 140deg and lowest in the list
2) Green when above 140
3) Yellow when above 200 (the open alarm for more detail)
4) Red when greater than 210
5) And finally a 'popup' message when greater than 220deg and it is highest in the list as we want it to be visible when the temp is critical
Hope this helps understand the order/layering that is needed.“
AiM Sports National Training Manager Roger Caddell showed how the order in which they are entered makes the difference in making this work.
The original query was: Looking for a little help with display measures...
Getting very inconsistent results with using display measures to change color of text data displayed on MXS 1.0 dash. For example trying to have RPM value change color to match the shift lights. First tried setting 'above 6200 = white' 'above 6800 = yellow' 'above 7200 = red' to no avail. Then thought maybe range triggers would work better and tried above > below variables for each of the ranges '6200>6799 = white on' '6799>6200' white on, '6800-7199 = yellow on' '7199>6800 = yellow on' and '7200-8000 = red on' '8000>7200 = red on' All of these resulted in RPM data on dash not change color at all.
Also tried similar data with oil and water temps which I had slightly more success with but not perfect. Set up range above/below and below/above for each data type same fashion as RPM above. The oil temp data seemed to follow this logic and change color depending on which range it was in. Water temp just stayed blue (coldest range) no matter what.
Maybe only certain data types can have the data change color depending on ranges?”
Roger’s answer was: Hi Ryan Vosburg, You are close :-)
I have attached a screen capture that shows that the order that you have the alarms 'stacked' matters. Think of it as layering and the 1st (lower temp colors in my example for water temp) must be lower in the list. In my example
1) The water temp text color is blue when less than 140deg and lowest in the list
2) Green when above 140
3) Yellow when above 200 (the open alarm for more detail)
4) Red when greater than 210
5) And finally a 'popup' message when greater than 220deg and it is highest in the list as we want it to be visible when the temp is critical
Hope this helps understand the order/layering that is needed.“
#6
In the AiM Users Group on Facebook, a fellow was having the same issue with the specific triggers not being “accepted” by the config.
AiM Sports National Training Manager Roger Caddell showed how the order in which they are entered makes the difference in making this work.
The original query was: Looking for a little help with display measures...
Getting very inconsistent results with using display measures to change color of text data displayed on MXS 1.0 dash. For example trying to have RPM value change color to match the shift lights. First tried setting 'above 6200 = white' 'above 6800 = yellow' 'above 7200 = red' to no avail. Then thought maybe range triggers would work better and tried above > below variables for each of the ranges '6200>6799 = white on' '6799>6200' white on, '6800-7199 = yellow on' '7199>6800 = yellow on' and '7200-8000 = red on' '8000>7200 = red on' All of these resulted in RPM data on dash not change color at all.
Also tried similar data with oil and water temps which I had slightly more success with but not perfect. Set up range above/below and below/above for each data type same fashion as RPM above. The oil temp data seemed to follow this logic and change color depending on which range it was in. Water temp just stayed blue (coldest range) no matter what.
Maybe only certain data types can have the data change color depending on ranges?”
Roger’s answer was: Hi Ryan Vosburg, You are close :-)
I have attached a screen capture that shows that the order that you have the alarms 'stacked' matters. Think of it as layering and the 1st (lower temp colors in my example for water temp) must be lower in the list. In my example
1) The water temp text color is blue when less than 140deg and lowest in the list
2) Green when above 140
3) Yellow when above 200 (the open alarm for more detail)
4) Red when greater than 210
5) And finally a 'popup' message when greater than 220deg and it is highest in the list as we want it to be visible when the temp is critical
Hope this helps understand the order/layering that is needed.“
AiM Sports National Training Manager Roger Caddell showed how the order in which they are entered makes the difference in making this work.
The original query was: Looking for a little help with display measures...
Getting very inconsistent results with using display measures to change color of text data displayed on MXS 1.0 dash. For example trying to have RPM value change color to match the shift lights. First tried setting 'above 6200 = white' 'above 6800 = yellow' 'above 7200 = red' to no avail. Then thought maybe range triggers would work better and tried above > below variables for each of the ranges '6200>6799 = white on' '6799>6200' white on, '6800-7199 = yellow on' '7199>6800 = yellow on' and '7200-8000 = red on' '8000>7200 = red on' All of these resulted in RPM data on dash not change color at all.
Also tried similar data with oil and water temps which I had slightly more success with but not perfect. Set up range above/below and below/above for each data type same fashion as RPM above. The oil temp data seemed to follow this logic and change color depending on which range it was in. Water temp just stayed blue (coldest range) no matter what.
Maybe only certain data types can have the data change color depending on ranges?”
Roger’s answer was: Hi Ryan Vosburg, You are close :-)
I have attached a screen capture that shows that the order that you have the alarms 'stacked' matters. Think of it as layering and the 1st (lower temp colors in my example for water temp) must be lower in the list. In my example
1) The water temp text color is blue when less than 140deg and lowest in the list
2) Green when above 140
3) Yellow when above 200 (the open alarm for more detail)
4) Red when greater than 210
5) And finally a 'popup' message when greater than 220deg and it is highest in the list as we want it to be visible when the temp is critical
Hope this helps understand the order/layering that is needed.“
Thanks for posting this...Pehaps Aim should put some documentation out there explaining this instead of having users run into these limitations themselves.
Even the other warning I received (and documented above) came about even though I still had spare alarms that had not been used. It's odd that on one hand, the device is "full", yet on the other hand, the software says differently.
#7
Rennlist Hoonigan
which cost no drachmas
Lifetime Rennlist
Member
Rennlist
Site Sponsor
which cost no drachmas
Lifetime Rennlist
Member
Rennlist
Site Sponsor
Joined: Dec 2001
Posts: 12,741
Likes: 1,037
From: Manchester, NH
The post Peter sighted is about alarms, not triggers. They each have a different limit and can work together. I'll try and look at your config today to see if I see anything.
Yes, the sequence is important.
Yes, the sequence is important.
Trending Topics
#8
Rennlist
Basic Site Sponsor
Basic Site Sponsor
Joined: Jun 2008
Posts: 19,273
Likes: 3,473
From: Durham, NC and Virginia International Raceway
Yes, with the increase in configurable options, we’re running into this more and more. It’s been pretty busy since the 1.2 display loggers have come out. The firmware and software updates that break working configs have been a challenge, too. But they’re trying. It’s good stuff for the price point.
#9
I suspect I already know the answer to when we might be able to actually fully configure our own displays like the Motecs and AEM's of the world
#10
Rennlist Hoonigan
which cost no drachmas
Lifetime Rennlist
Member
Rennlist
Site Sponsor
which cost no drachmas
Lifetime Rennlist
Member
Rennlist
Site Sponsor
Joined: Dec 2001
Posts: 12,741
Likes: 1,037
From: Manchester, NH
Looking at the configuration more, I'm also noticing that certain configurations that I make in the software (eg. to display certain parameters in certain colours) are not carried out. For example in the configuration above, I have it set up to display gear position in red. Yet, when I send the configuration to the dash, gear position is still displayed in white.
I also came across an interesting warning this morning while making a few configuration changes - ".*config file name here* has a number of Math Channels or Alarms that exceed the maximum admitted. Please delete"1" elements to avoid missing data.......Do you want to transmit anyway?"
Not sure if I'm running into a bug or some limits as far as how many channels the MXG can deal with here.
I also came across an interesting warning this morning while making a few configuration changes - ".*config file name here* has a number of Math Channels or Alarms that exceed the maximum admitted. Please delete"1" elements to avoid missing data.......Do you want to transmit anyway?"
Not sure if I'm running into a bug or some limits as far as how many channels the MXG can deal with here.
I would suggest sending your config into software@aim-sportline.com. They have a person who takes problems like this, sets the system up to mimic yours, and tests it.
#11
Rennlist Hoonigan
which cost no drachmas
Lifetime Rennlist
Member
Rennlist
Site Sponsor
which cost no drachmas
Lifetime Rennlist
Member
Rennlist
Site Sponsor
Joined: Dec 2001
Posts: 12,741
Likes: 1,037
From: Manchester, NH
They are working on adding more features in RS3 so you can do this, but it's an involved process to allow it. When I was at the factory, I saw how they build the screen images and the work that goes to do it which is certainly something far beyond most users abilities. They are working in more and more ways for people to customize their displays though.
#12
In the config you put on Dropbox, I don't see anything wrong looking through it. In that config, you have 1 alarm left and 1 trigger. In the message you received, I'm not sure what it would miss if you transmitted the config and used it.
I would suggest sending your config into software@aim-sportline.com. They have a person who takes problems like this, sets the system up to mimic yours, and tests it.
I would suggest sending your config into software@aim-sportline.com. They have a person who takes problems like this, sets the system up to mimic yours, and tests it.
#13
They are working on adding more features in RS3 so you can do this, but it's an involved process to allow it. When I was at the factory, I saw how they build the screen images and the work that goes to do it which is certainly something far beyond most users abilities. They are working in more and more ways for people to customize their displays though.
#14
Rennlist Hoonigan
which cost no drachmas
Lifetime Rennlist
Member
Rennlist
Site Sponsor
which cost no drachmas
Lifetime Rennlist
Member
Rennlist
Site Sponsor
Joined: Dec 2001
Posts: 12,741
Likes: 1,037
From: Manchester, NH
#15
Rennlist
Basic Site Sponsor
Basic Site Sponsor
Joined: Jun 2008
Posts: 19,273
Likes: 3,473
From: Durham, NC and Virginia International Raceway