Charmed Quark Systems, Ltd. - Support Forums and Community

Full Version: Problem with B&K Driver / Keypad
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I have seen this issue in the past, but usually seemed to fix itself, but now it is seems to persist.  I have a B&K CT600.1 and am using the shipped driver.  I have keypads where I have programmed the buttons to do certain tasks via the USB-UIRT. (i.e. press a button, it sends an IR code out to the USB-UIRT, and CQC receives it and processes)  I set this up about a year ago and it has worked fine up until recently.  I now get no response from the key presses, but I do get these error messages in the system log.

I checked the actions programmed by themselves, and they work fine, so it has to be something regarding the key press not being understood by the B&K driver and it is displaying these messages.  I have rebooted the server, and reset the B&K CT600, but no change.

Any thoughts on what might be causing this?  I pressed several buttons to get this response.  Again it has worked in the past, but hasn't the last week or so.  The attached error messages show up during the key presses.

Currently on 5.3.919

It looks like the driver doesn't understand what the B&K is sending. Weird that that would work for a while and then quit. I wonder if what it sends can change in some way based on button pressed? Does it happen for all of the buttons?

Since you are on the betas anyway, I'd say move on up to the latest. If it's still happening, we can dig into it more deeply.
(02-28-2019, 11:25 PM)Dean Roddey Wrote: [ -> ]It looks like the driver doesn't understand what the B&K is sending. Weird that that would work for a while and then quit. I wonder if what it sends can change in some way based on button pressed? Does it happen for all of the buttons?

Since you are on the betas anyway, I'd say move on up to the latest. If it's still happening, we can dig into it more deeply
I upgraded to the latest Beta and have the same problem.  Since I have two B&K CT600.1's, and getting the same messages on both of them, it points me to a driver issue.  95% of the time the key presses fail with an error message, but sometimes it works.  In the past it did work fine  -figure it has to be a timing issue of some sort with the serial communications.
I have seen these messages before in the past, but infrequently, so I really never thought much about it - I would press the key again and it would work.  I am now seeing them on almost every key press, so I am thinking that the driver maybe doesn't always interpret what is being sent. I am going to put it in the test harness and see if I can figure out where it is failing, as it appears from the error message that the data is getting to CQC, but is not being interpreted properly.  Everything works fine if I use the IV or send the USB-UIRT commands directly.  Maybe the developer didn't use keypads like I am and was unable to test them.
The errors in the log above are all about the checksum being incorrect. So maybe there's some subtlety in the calculation of the checksum that the driver isn't getting right. I'd put a break point at the point there where it logs that checksum error and hit the button until it hits the break point. Then you should be able to see what it's calculating.
I finally got around to putting this into the test harness, and I am getting an error on compile.  Before I mucked around and attempted to fix this, I thought you better look at it.  Interesting that the driver works fine except for these chksum errors it is throwing, but it won't compile.

The compile error says that Parameter 1 is Out or InOut, so only non-const values can be passed here:

The offending line below is:   strValue:=m_Helper.ProcessString(Value);

   Method WriteSystemValue( [In] String Setting, [In] String Value)
           Card4   crdZone;
           Int4    intData;
           Card4   crdData;
           String  strData;
           Boolean blnData;
           SystemVals  SysVal;
           Card4       CurPos;
           String      strValue;

           Switch (SysVal)
               Case SystemVals.Input1Title, SystemVals.Input2Title,SystemVals.Input3Title, SystemVals.Input4Title, SystemVals.Input5Title,
                       SystemVals.Input6Title, SystemVals.Input7Title, SystemVals.Input8Title, SystemVals.Input9Title:

                   //This is the title settings
                   //CurPos := Setting.ToCard4R(Radices.Hex);
                   If (CurPos=0)
                       //This is the first input setting, clear the string
                       m_InputList:="FM, AM, Dedicated, ";
                       m_Inputs[2]:="Dedicated In";
                   m_Inputs[CurPos + 3]:=strValue;
                   m_InputList.Append(", ");
                       m_InputList.Cut(m_InputList.GetLength() - 2, 2);

               Case SystemVals.Input1Level, SystemVals.Input2Level, SystemVals.Input3Level, SystemVals.Input4Level, SystemVals.Input5Level
                   , SystemVals.Input6Level, SystemVals.Input7Level, SystemVals.Input8Level, SystemVals.Input9Level:

                   //This is the Input Level
                   CurPos:=CurPos - 16;

               Case SystemVals.HWZoneATuner:
                   WriteCardFld(m_FldId_HWZoneATuner, crdData);

               Case SystemVals.HWZoneBTuner:
                   WriteCardFld(m_FldId_HWZoneBTuner, crdData);

               Case SystemVals.HWZoneCTuner:
                   WriteCardFld(m_FldId_HWZoneCTuner, crdData);

               Case SystemVals.HWZoneDTuner:
                   WriteCardFld(m_FldId_HWZoneDTuner, crdData);

               Case SystemVals.HWZoneETuner:
                   WriteCardFld(m_FldId_HWZoneETuner, crdData);

               Case SystemVals.HWZoneFTuner:
                   WriteCardFld(m_FldId_HWZoneFTuner, crdData);



               //do nothing, we are not looking for this command, so ignore this error


           m_Log.LogMsg3("Error Writing Sys Cmd. Error=%(1) Setting=%(2) CmdData=%(3)"
               , $Exception.GetErrorText(), Setting, Value
He is passing in Value as an [In] which means it's constant. But his m_Helper.ProcessString() obviously modifies the string, so that's not legal. Given that ProcessString() returns a new string, I'm guessing that this is a mistake and that ProcessString()'s parameter can be [In] as well. If not, then ProcessString should just be changed to make the parameter an [In], then it should make a copy of the incoming string, process that, and return it. I would have thought that is what would be doing anyway, and it may just be a mistake that it's not marked as [In] already. So try that. If the compiler complains because it's using the parameter in a way that it's trying to change it, just change it to use a local copy instead.
I got it back up and working - It ended up being an issue with USBUIRT, not the B&K driver - I relocated the location of it after reading one of the threads about possible electrical interference, and it started working again.

On the B&K driver, I copied "value" to a local string in each place where value was being passed, and passed the local string instead, and got it to compile.  It ends up the chksum errors occur on every keypress from the keypads, which I had noticed before but never realized if was on every keypress.  However, the driver still sends the command along so it is more informational - It looks like the keypress chksum error is because it is not adding a close parenthesis, and he is catching that error.  I am going to place that section into a Low Verbose level catch rather than on every chksum error - it will clean up the log files for me quite a bit since I use the keypads often.
I am having an odd problem with updating the B&K driver to make it skip checksum messages on keypad presses.  I am a CML novice, but have done this many times in the past - explanation below:

I copied over the Macros\System\CQC\Drivers\BnK\CT folder to Macros\User\CQC\Drivers\BnK\CT11, created a new manifest in the \Manifests\User that points to this new user folder.

In the "Develop CML Drivers", I made all the modifications to reference the User folder (their were 5 files there), and it compiles, run, and works without problem.  When I select No Verbosity - No messages in Log - when I select Low Verbosity, I get the keypad checksum errors - it all works great.  I saved all the files and closed the program.

I reset the CQC Application Shell, saw the new driver in the driver list, and installed. It does not work like it did in the Driver Harness - I get all of the same chksum errors as before. The driver info shows it is pointing to the correct folder.  I have checked and double checked the driver files and manifest, and it continues to work as I planned in the Driver Harness, but not when installed.  I am sure it is something simple that I am missing, but can't figure it out.

I could create a CQC driver pack and install and maybe that would fix the problem, but thought I would ask before doing so.
Did you change the make/model? That's the unique key. So you have to add -Dev or some such to the model of your working one. Once you do that, create a new package and import to get the new manifest in place, then try it again. Unload the driver and then reload it and select your new guy.
(03-19-2019, 11:42 AM)Dean Roddey Wrote: [ -> ]Did you change the make/model? That's the unique key. 

I didn't, and once I did, that fixed the problem.  Thanks a ton!