PEAK-System Forum

I have just started looking at the PCAN-Basic (I haven't even received my hardware yet), so I'm sure I'm just unable to find this, but what is the proper way to address multiple devices in the same computer? For example, if I have two PCAN-PCI Express 2ch, how do I initialize them so that I could properly map all 4 of the channels they support?

What I see so far is, for example, PCANBasic.Initialize(PCANBasic.PCAN_PCIBUS2, TPCANBaudrate.PCAN_BAUD_500K), where the first parameter is a channel handle and varies from PCANBasic.PCAN_PCIBUS1 to PCANBasic.PCAN_PCIBUS16. Does that mean there is an abstraction, where one cannot distinguish from, say, having four PCAN-PCI Express 1ch or a single PCAN-PCI Express 4ch? And, is then 16 the maximum number of CAN channels that can be supported on a single computer? If it matters, I'm writing C# code.

This is kind of important for my software because we use device/channel-level licensing and also the act of replacing a board must be detected. We do that by, e.g., reading serial numbers of boards, and I don't see that supported here. Could you, please, provide some more information about this subject? Thanks!

Kamen

Hi,

the CAN channels of the PCAN-PCIe cards will be listed by the driver in the order they will be detected from the BIOS of the system. When you use several cards, it can happen that the cards will be detected different during different bootups. That is why we offer to fix the handles by setting registry keys. See the following post for more details:

https://www.peak-system.com/forum/viewt ... f=15&t=998

Yes, the PCANBasic API only supports up to 16 channels per device (PCI, USB, etc.). Reading serialnumbers from the PCAN-PCIe boards is not supported.

regards

Michael

Thank you, Michael,

For now I will only have one PCIe board to try, but I'd like to know this would work for when the issue comes up in production. So, let me make sure I understand how this would work, if I followed the described approach to map device channels to handles:

Let's say I've mapped channel 2 of my second PCIe card to PCAN_PCIBUS4 and I also had three USB devices, where I had mapped the third one to PCAN_USBBUS3. Of course, I have used the above-referenced procedure to "fix" the handle to the hardware channel. Then, if I were to remove all other PCAN hardware but those two, will the mappings remain, i.e., the above hardware channels would still map to PCAN_PCIBUS4 and PCAN_USBBUS3? What if I also added other PCAN hardware in mean time? Would the mapping be preserved? What if I moved the previously-mapped PCI device to a different USB port? Those are all scenarios that our customers would face at one time or another.

Any plans to move to an approach that uses unique IDs in the future? That is, adding device serial number entries in firmware that can be read though your API? That shouldn't be very difficult to implement and would cause no backwards-compatibility problems.

Lastly, I just want to clarify your penultimate statement above: PCAN-Basic API only supports up to 16 channels per device type (not just device instance)?

Kamen

Hello,

Kamen wrote: if I were to remove all other PCAN hardware but those two, will the mappings remain, i.e., the above hardware channels would still map to PCAN_PCIBUS4 and PCAN_USBBUS3?

The fixing channels only work when all your cards are attached. If you remove what you call PCAN_PCIBUS1, and PCAN_PCIBUS2 without having connected 3 or 4, then the remaining channels "will change" to PCAN_PCIBUS1 and PCAN_PCIBUS2 (3 and 4 will not be found anymore).

Kamen wrote:What if I also added other PCAN hardware in mean time? Would the mapping be preserved?

There is no problem adding more hardware, if all hardware involved in the mapping are present. Additional hardware will just maps additional channels (PCAN_PCIBUS6, PCAN_PCIBUS7, etc)

Kamen wrote:What if I moved the previously-mapped PCI device to a different USB port?

The physical USB port used doesn't affect the mapping.

Kamen wrote:Any plans to move to an approach that uses unique IDs in the future? That is, adding device serial number entries in firmware that can be read though your API?

Not yet. Most customers don't use complex constellations when using PCAN-Basic. For complicated scenarios they use PCAN-Developer.

Kamen wrote:That shouldn't be very difficult to implement and would cause no backwards-compatibility problems.

I have a different opinion. You are talking about doing a change in a firmware from a device, that is being sell thousands of times and about a change in an API that potentially include a new function. New software for manufacturers, new tests, etc. This is indeed "not a piece of cake" and there can be a lot of backwards-compatibility issues starting with those people using the dll in a static way. Using a serial number for connection just break the way PCAN-Basic works. We don't say it is perfect, but it has also limitations.

Kamen wrote:Lastly, I just want to clarify your penultimate statement above: PCAN-Basic API only supports up to 16 channels per device type (not just device instance)?

You can connect per device type (USB, PCI, LAN, etc) up to 16 devices (PCAN-USB Pro, PCAN-USB Pro FD, etc) at the same time. For instance, you can have 4 PCI cards (each with 4 channels) connected, and at the same time 16 PCAN-USBs. In this example you have 32 channels connected, but you cannot connect any other USB or PCI device more, since each device type has reached the maximum amount of connections.

K.Wagner wrote:Hello,

Kamen wrote:That shouldn't be very difficult to implement and would cause no backwards-compatibility problems.

I have a different opinion. You are talking about doing a change in a firmware from a device, that is being sell thousands of times and about a change in an API that potentially include a new function. New software for manufacturers, new tests, etc. This is indeed "not a piece of cake" and there can be a lot of backwards-compatibility issues starting with those people using the dll in a static way. Using a serial number for connection just break the way PCAN-Basic works. We don't say it is perfect, but it has also limitations.

I appreciate your efforts to respond to my inquiries, but I really don't understand how any time some capability of your product is questioned, the effort is mostly focused on defending it rather than trying to accommodate the need of the customer. Before I go on, let me make it clear that the reason why I am sticking to the PCAN-Basic and not PCAN-Developer is not because I don't want to spend the money, or anything like that, but because I want something simple and the basic library fits my paradigm much better: I don't want to have to deal with "nets" or "constellations", or any of the complexities relating to vehicle networks. Our software is a test-automation development platforms and uses a channel-based abstraction to communicate with unlimited types of hardware I/O. All I want is a way to allow the user to define channels (in this case, via CAN signals) and use them in our software. However, each defined channel gets a unique ID (and is licensed accordingly) and I don't want this ID to change for no good reason, like unplugging a board/USB device and plugging in others. I need a reliable way to generate that ID, associating it with the actual hardware. Even in the old days of COM ports, the National Instruments boards we used, which would change associations based on the order they were plugged in, had a utility from NI that would let you correct the port assignments. Most manufacturers have some mechanism to deal with that.

Specifically about the change in your libraries to support reading hardware serial numbers. This, just like my question about adding support for enumerating available PCAN channels (https://www.peak-system.com/forum/viewt ... =41&t=3103), shouldn't be nearly as hard as you make it sound. Any issues relating to software changes arise when you are modifying existing behavior and this would only be an addition - I'm not suggesting any change in the current behavior of the libraries. Since none of the existing functions would require a change, there should be zero issues with backwards compatibility and no current users would be affected in any way. As for the firmware, I'm confused: is the functionality there or not? You suggest that with PCAN_Developer what I'm looking for is achievable, so there must be some way to read this information from the device? If not and firmware does need to be changed, then - yes, that may be a little more involved, but it is still a worthy change. And adding this new functionality should require much less testing than the one you go through with any new release. Of course, as long as you don't inadvertently introduce any bugs in the process.

I am not trying to argue here - if you don't want to plan any changes to your software based on customer input, you don't have to. I am simply trying to make sure you do understand what I am suggesting. If you want to make those changes, I'd be willing to work with you to make it easier (specification, feedback, testing, etc., even financial support). But if you don't want to do it, there is no point of explaining why you are not going to do it. Before asking my questions, I looked through the forum, trying to find answers. In the process I was surprised to see a lot of arguments about how and why the customer was "wrong". Nobody wants to see that, so I don't know why you bother. I'm not some kid who needs to be educated about how things are "really done"; I have decades of experience and I know how they are actually done. I'll find a way to get it done, one way or another. And if you want to help, I'll work with you to make your product better. But if you don't, there is no need to waste time with excuses.

Kamen

Ok, I think we are losing the topic here. But to have things clears, I never tried to teach you anything about how things work. You gave me an opinion about something, and I gave you mine. That is all. If you feel like attacked then, sorry, maybe I gave you to many details.

I believe that you have a lot of experience, but this doesn't means that you can understand what is internally happening in PCAN-Basic. Without wanting to offend anybody, to think one can, could be categorised as arrogance. There are several things you are not aware (some company secrets inclusive), so believe me when I say, "it is not so easy"! . I don't want to get in detail on this, but I asking you to respect this.

Kamen wrote:As for the firmware, I'm confused: is the functionality there or not? You suggest that with PCAN_Developer what I'm looking for is achievable, so there must be some way to read this information from the device? If not and firmware does need to be changed, then - yes, that may be a little more involved, but it is still a worthy change.

Each company have different rules and policies. In our case, devices don't have a serial number in memory, they only have them written on their parts. So there is no way to read them with any API. Customers that really need a serial number use the Developer package, since this allow to write and read a small range of memory, so they can use their own serial numbers and check for them too. Note too, that this is only true for PCAN-USB FD devices. No other device type of PEAK supports this. Note that I'm not trying just to sell a Developer package (it have not overhead just by using it, but also by supporting it), but it is fact, that this is only available for the developer package. I even not sure if other devices have memory at all available

Kamen wrote:I am not trying to argue here - if you don't want to plan any changes to your software based on customer input, you don't have to. I am simply trying to make sure you do understand what I am suggesting. If you want to make those changes, I'd be willing to work with you to make it easier (specification, feedback, testing, etc., even financial support).

Many of the current functionality is because of customer requirements. I understand your need, and you are not alone. I'm looking myself since some time ago for a solution for this connection problematic and have found nothing until now. Again, it seems easy to the outside but the internal processes isn't. If you have specific ideas, you can share them with us but the forum is a bad place for it. Write an email with your ideas and explanation to info[at]peak-system.com, or support[at]peak-system.com and we will check the viability of them. I/we want also that the product get better (just remember, there is not guarantee that we implement it )

About your comment:

Kamen wrote:I was surprised to see a lot of arguments about how and why the customer was "wrong". Nobody wants to see that, so I don't know why you bother.

Ok, this is like you want to tell me now how I need to do my support? I will save myself the comment about my experience. Well, of course people want to see that, at least my colleagues of the support department. We have several cases were other customers were confused because of wrong assumptions. There are customers that think they know everything and the rest of the world is wrong, and yes, in those cases I defend our products maybe to hard, but they are days when you cannot do anything else. Many of them contact us first per email and because they don't get what they want, they strat topics in our forums trying to get more attention. Again, you don't know the truth 100%.

Kamen wrote:And if you want to help, I'll work with you to make your product better. But if you don't, there is no need to waste time with excuses.

OK, I hope you don't see this as an attack (since it is not). There are also not excuses, just the truth from my point of view. If you still need to say anything I will suggest an email since this post is already out of topic. I hope you appreciate the time I took to answer your post. And again to the problem, if you are using PCAN-USBs, you can use the Device-ID to always recognize a channel (I'm working in a version that allows you to read this value without connecting you to the channel). PCI have unfortunately no Device-ID - for this case I have no solution, sorry.

Hello, Kenneth,

Actually, this response of yours was by far the most constructive and it finally shed light on some questions I had asked, and also guided me towards a more efficient way of communication - I did not realize I could get support via email, I was directed to the forum when I searched for support on the PEAK website. The downside of direct email is that any solutions would not be shared with the community, but I guess I could write a summary at the end.

I'll be writing the email now.

Kamen