PEAK-System Forum

Is there are better way of enumerating the CAN bus communication channels available in a system than simply probing in order: PCAN_PCIBUS1, PCAN_PCIBUS2, ..., PCAN_PCIBUS16, PCAN_USBBUS1, PCAN_USBBUS2, ..., PCAN_USBBUS16, and so on? Those aren't even consecutive numbers, even though, one shouldn't be making assumptions about the numeric mapping, if they were.

Kamen

If you want to know which Devives and channels are availabel , you simply run to a loop and check all - not much lines of code. The reason why the numbers for the Channels are not in a "row", is need to be compatible with older Software that did not support so much CAN Channels. Is it as it is - we could not change, but it is also no real problem. As a software developer you could simply map the Channels into a array and use this index to enumerate and check the channels so all in one single loop. If you want one single call to get all info - write a own function that handle it - use own structures for all channels with there "availability" - but this is up to you - most customer do not need it. The simply use 1 or 2 channels and check by reading the Device Number which channel is which device.

Thank you, I understand. It is not about the effort writing a few extra lines of code. It is about stability and future-proofing. What if in future editions of PCAN-Basic there are new types of handles? Like, for a new communications bus. We'd have to add code to support it. As opposed to having a function in the library that returns all available handles. In this case, all we'd need is have our customers keep their PEAK drivers (DLL, etc.) up to date - makes them feel much more confident (single-point of failure vs dual). Plug-and-play and future-proof. All I'm saying is: there is much more value in PEAK supplying such a function in their library, rather than having the integrators write their own. And there is a big difference between something as fundamental as device discovery and all other functions that one would need, so it doesn't get much further.

Kamen

This is your point of view, we think that less is more - keep API DLLs simple! Users could very easy implement such features by their own if they really need it. Also for most customer it is a must that new Hardwaretypes should NOT work out of the BOX with their(older) applications, because they have not checked if their application/systems really support this device. (See new Virtual Network Devices - some customers do not want that their APPs work with this type, because of timing issues).