VB filter problems

I am working with a mature VB6 program which utilizes the USB to CAN Compact hardware. Most recently, program has been working as expected using vci_3_5_2_4268 drivers plus vci_2_20_855_0 wrapper.

I’m attempting to update to vci-4_0_848_0 drivers and use vci2onvci4_2_30_72_0 wrapper.

After driver installs, canAnalyser3 Mini program runs correctly. My VB program properly connects with the USB to CAN hardware. Problem is setting a filter for Rx buffer does not work as I expect. In fact, the only way I can get any message through the filter is to completely open it. Bit shift left is not the solution (although this was not needed with the vci_2_20_855_0 wrapper and version 3 drivers). I have streamlined acceptance code and mask down to looking for a single bit with no luck.

This is code which works with older versions of drivers:
'Change mask - open to include ISO Acknowledgement 059392 (18E800)
intRetVal = oVCI.VCI_AssignRxQueObj(intBoardHdl, _
g_lngInitRxHdl, VCI_ACCEPT, &H18EE0000, &HFFF80000) 'Mask was &HFFFF0000

Along with a lot of other variations, this is code altered for version 4 drivers and results in no message passing filter:
intRetVal = oVCI.VCI_AssignRxQueObj(intBoardHdl, _
’ g_lngInitRxHdl, VCI_ACCEPT, LShiftLong(&H18EE0000, 1), &H3FF00000)

This is only form I have found to pass anything and it passes all:
intRetVal = oVCI.VCI_AssignRxQueObj(intBoardHdl, _
’ g_lngInitRxHdl, VCI_ACCEPT, LShiftLong(&H18EE0000, 1), &H0)

Your assistance is greatly appreciated!

Hi @greg_11A

Sorry for the delay, I think I may need to escalate this to some colleagues over in Sweden and find out some info on this for you. You should be getting an email for this escalation shortly.

Thanks,
-Tim

Has anyone been able to look into the problem I reported?

Hi Greg,

Sorry about that, when I escalated the ticket it should have sent you a message with the reply they gave. Can you check your email and let us know if you ever got an email for case number 201906-6822? If not then we may have an issue with our escalation system.

The Beta VCI driver below should include some filter changes that would help out with this.

" [x] VCI_SetAccMask: internally mask code with mask parameter as in original VCI2 implementation (1829-27858)
[x] VCI_ResetBoard: delete queues and buffers within ResetBoard (1829-27858)
[x] VCI_AssignRxQueObj: fix filter implementation according to test cases (1829-27858)
[x] VCI_AssignRxQueObj: fix filter implementation according to test cases (1829-27858)
[x] VCI_AssignRxQueObj: treat ACCEPT case as in VCI 2.xx (mask the code with given mask value)
[x] Receive queues: do not start a message thread when int_limit = 0"

VCI2onVCI4_2_31_104_01-BETA (1) (1).zip (1.2 MB)

Thank you Tim. I did not receive the original response. I’ll give this build a try.

Regards,

Greg

Tim,

Wanted to say thanks. The 2_31_104_01-beta build did the trick. A seamless transition for the old VB program.

Greg

1 Like

Thanks for the update, I’ll let them know that this fixed the issue!

Upon further evaluation, it appears that 2_31_104_01-beta has not completely resolved the issue. The acceptance filter function still does not perform in the same manner as the older vci-v2-20-855-0.

The receive cue is being set with the following code:
'This sets acceptance mask for CCP Test function call to verify ready for CCP session
intRetVal = oVCI.VCI_AssignRxQueObj(g_intBoardHdl, g_lngInitRxHdl, _
VCI_ACCEPT, CLng("&H18EF" & g_strSource & “00”), &HFFFFFF00)

In this example, g_strSource is set to 0x00

I am finding that messages with ID of 18EE are being passed through the filter. The full message ID is 18EEFF01. This message is not accepted with the older VCI2 driver set.

Would you please have staff take another look at it?

Regards,
Greg

Hi Greg,

I’ll get in touch with my colleagues and see what I can find out for you

Hi Greg,

I was talking with my colleague in Sweden and he was saying that he saw some issues with this statement:

intRetVal = oVCI.VCI_AssignRxQueObj(g_intBoardHdl, g_lngInitRxHdl, _VCI_ACCEPT, CLng("&H18EF" & g_strSource & “00”), &HFFFFFF00)

g_strSource is set to 0x00

He was saying that should mean this:
ID = 0x18EF0000
Mask = 0xFFFFFF00

For this reason He was saying that only messages with 18EF00xx should pass instead of 18EFxxxx

Hi Tim,

I agree with your colleague. Only messages with 18EF00xx should pass instead of 18EFxxxx . In these particular circumstances, the VB program code is established in a CCP session with a particular device. The address claimed by the program is 0x00.

The problem I find with using the vci2onvci4 beta build is that setting the ID and mask as stated, the filter is allowing an address claim message (18EExxxx) to pass as well as 18EF00xx messages. The older vci-v2-20-855-0 performs exactly as your colleague states.

Hope that helps.

Greg

Hi Greg,

Here’s what I heard back from my colleague:

" I attached a VB6 example where I set following filter:

intRetVal = objVCI.VCI_AssignRxQueObj(intBoardHdl, lngRxQueHdl, VCI_ACCEPT, &H18EF0000, &HFFFFFF00)

And when I send with MiniMon I see only the ID 0x18EF0001 and not the 0x18EF1234.

I tested also 0x18EE9999 which also did not pass.

Can he try it with the attached sources (I set 500 kBit as baudrate inside, he should change to his one)?"

VCI2_VB_Polling.zip (2.7 KB)

He also included a C++ example code that may be of some help to you:

https://fileshare.hms.se?container=B4JY9bc3NQ2rS2Re9U48Fz8NB5sS6XN4685Nt4K93Ss2M

Hi Tim,

The sample code, supplied by your colleague, was most helpful. I ran that code and saw that the filter performed exactly as intended. It passed only the intended message. Yet my program continued to pass more than I expected. I’m afraid I pondered the difference for too long before realizing what the difference was. Let me explain with snippets of the program code:

When program begins, I do typical prep for the hardware

oVCI.VCI_SelectHardware

oVCI.VCI2_PrepareBoard

oVCI.VCI_ReadBoardInfo

oVCI.VCI_InitCan

Next initialize transmit & receive buffers:

intRetVal = oVCI.VCI_ConfigQueue(intBoardHdl, 0, VCI_TX_QUE, 20, 0, 0, 10, lngTxQueHdl)

intRetVal = oVCI.VCI_ConfigQueue(intBoardHdl, 0, VCI_RX_QUE, 40, 1, 0, 10, lngRxQueHdl)

When program connects to CAN network, the following code is implemented:

'Set filter for ISO Address Claim messages
'Change mask - open to include ISO Acknowledgement 059392 (18E800)
intRetVal = oVCI.VCI_AssignRxQueObj(intBoardHdl, g_lngInitRxHdl, VCI_ACCEPT, &H18EE0000, &HFFF80000) 'Mask was &HFFFF0000

oVCI.VCI_StartCan

Up to this point, all is good and my program performs just like the sample code supplied. FIltering works exactly as expected. The program enumerates all devices present on the CAN network. The user is to then select a device from created list to establish a communication session. Here is where my program code departs from the sample program and where I create the problem with Rx filter:

Select device

intRetVal = oVCI.VCI_AssignRxQueObj(g_intBoardHdl, g_lngInitRxHdl, _
VCI_ACCEPT, CLng("&H18EF" & g_strSource & “00”), &HFFFFFF00)

My intent here was to change the Rx filter from 18E8xxxx - 18EExxxx to 18EFxxxx. Using the old VCI-V2-20-855-0 wrapper, it appears that the filter is indeed changed from the first ID group to the second group. Using the VCI2 on VCI4 wrapper, my findings indicate that the filter is set for both of these ID groups rather than the second replacing the first. This is why I initially thought the mask was not functioning properly.

I tried the following code to get the filter acting as I wanted - shift from first group to second group:

’ intRetVal = oVCI.VCI_ResetCan(g_intBoardHdl, 0)

’ intRetVal = oVCI.VCI_AssignRxQueObj(g_intBoardHdl, g_lngInitRxHdl, _
VCI_ACCEPT, CLng("&H18EF" & g_strSource & “00”), &HFFFFFF00)

’ intRetVal = oVCI.VCI_StartCan(g_intBoardHdl, 0)

The above attempt appeared to make no difference in filter actions. Finally, I tried the following code and the filter now worked as expected, allowing only 18EFxxxx to pass:

Select device

lngRetVal = oVCI.VCI_SetAccMask(g_intBoardHdl, 0, CLng("&H18EF" & g_strSource & “00”), &HFFFFFF00)

The above is a viable solution for my program. I can make the change and the end user should have a seamless transition from VCI2 to VCI4. What I am hoping is that you could provide me with some education as to the proper way, if any, to change the filter from one message to another. My lack of understanding of the filter mechanism is causing me to work around the issue. I’d like to know the proper intended implementation.

Thanks to all for the assistance,

Greg

Hi Greg,

Here’s what I heard back from Peter

"I can confirm it.

After setting a filter one time with VCI_AssignRxQueObj(…) the filter is set ok.
Calling it a second time the function will not change anything.

On a real VCI 2.18 it works as expected. I test it only with extended IDs.

  1. ret = VCI_AssignRxQueObj(BoardHdl, RxQueHdl2, VCI_ACCEPT, 0x18EF0000, 0xFFFFFF00);
    All Identifiers pass.
  2. INT32 ret = VCI_ResetCan(BoardHdl, CAN_NUM);
    ret = VCI_AssignRxQueObj(BoardHdl, RxQueHdl2, VCI_ACCEPT, dwFilterID, dwFilterMask);
    ret = VCI_StartCan(BoardHdl, CAN_NUM);
    On VCI2onVCI4 -> nothing changed, all identifier pass
    With VCI 2.18 now only the identifiers 0x18EF0001 till 0x18EF00FF pass

I will give it to the developers."

Morning Tim,

Just wanted an update on VCI2 on VCI4 problem reported and verified. Do you have an idea as to when a solution might be available?

Regards

Hi Greg,

Tim is traveling this week. I checked in with Peter and he gave me this VB example for you to confirm that the used function sequence works as expected. He is working with the developers to try to add this to the wrapper directly and is meeting with them next week.

VCI4_VB_Polling_Filter_Demo_V02.zip (3.3 KB)

Kyle

Hi Kyle,

Well the sequence Peter provided appears to work. It seems that the wrapper now functions as it did with the older VCI 2 drivers. It would be most appreciated if the vCI4 on VCI2 wrapper could be altered in the near future.

Thanks again to all for their efforts.

Regards,

Greg

Hi Greg,

Glad we could get the device up and running. Would it be alright to mark this case solved for now?

Thanks,
-Tim

Hi Tim,

Yes the issue appears solved. If the developers will alter the wrapper code, please let me know when available.

Greg Remmers

Engineer Expert