VB filter problems


#1

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!


#2

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


#5

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


#6

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)


#7

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

Regards,

Greg


#8

#9

Tim,

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

Greg


#10

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


#11

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


#12

Hi Greg,

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


#13

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


#14

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


#15

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