CAN controller

[bertr2d2]

Hi,

I don't have any problems with my setup (github kernel from ~ 8th of September):

Code: Select all

[    0.000000] Kernel command line: 
dma.dmachans=0x3c 
bcm2708_fb.fbwidth=656 
bcm2708_fb.fbheight=416 
bcm2708.boardrev=0x2 
bcm2708.serial=0x89c9XXXX 
smsc95xx.macaddr=B8:27:EB:XX:XX:XX
dwc_otg.lpm_enable=0 
dwc_otg.fiq_fix_enable=1
console=ttyAMA0,115200
kgdboc=ttyAMA0,115200
console=tty1
root=/dev/mmcblk0p2
rootfstype=ext4
elevator=deadline rootwait

root@raspberrypi ~ # uname -a
Linux raspberrypi 3.2.27+ #4 PREEMPT Sat Sep 8 17:54:31 CEST 2012 armv6l GNU/Linux

root@raspberrypi ~ # cat /proc/interrupts
           CPU0       
  3:   11478375   ARMCTRL  BCM2708 Timer Tick
 32:  304138785   ARMCTRL  dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb1
 52:   32194224   ARMCTRL  BCM2708 GPIO catchall handler
 65:          2   ARMCTRL  ARM Mailbox IRQ
 66:          1   ARMCTRL  VCHIQ doorbell
 75:          1   ARMCTRL
 77:     775561   ARMCTRL  bcm2708_sdhci (dma)
 80:  194563526   ARMCTRL  bcm2708_spi.0
 83:         20   ARMCTRL  uart-pl011
 84:    2210967   ARMCTRL  mmc0
195:   32194224      GPIO  can0
FIQ:              usb_fiq
Err:          0

root@raspberrypi ~ # uptime
 21:15:23 up 12 days,  2:53,  1 user,  load average: 0.00, 0.01, 0.05

Regards Gerd

[maddin1234]

Hi,
I found out something new:
In Gert's post I found that the interrupt for the GPIO Pin 25 is no more 110 but 195.

I changed the bcm2708.c to the new interrupt, recompiled and now I can "ip link..."
with fiq_fix_enabled = 1.

Is it possible, that the interrupt-numbers are changing according to the fiq_fix_enabled bit?

Then it will be time to change the static interrupt-assignment to a run-time assignment,
like AlexB posted somewhere before.

In case you still need them, here are the interrupts

interrupts.zip

(1.53 KiB) Downloaded 615 times

best regards and many thanks

maddin1234

[bertr2d2]

The IRQs might change in the future, so I would suggest following patch to the board definition:

Code: Select all

--- bcm2708.c_org	2012-09-21 14:33:39.102730640 +0200
+++ bcm2708.c	2012-09-21 20:19:09.560050330 +0200
@@ -54,6 +54,12 @@
 #include <mach/vcio.h>
 #include <mach/system.h>
 
+#include <linux/can/platform/mcp251x.h>
+#include <linux/gpio.h>
+#include <linux/irq.h>
+
+#define MCP2515_CAN_INT_GPIO_PIN 25
+
 #include "bcm2708.h"
 #include "armctrl.h"
 #include "clock.h"
@@ -579,10 +585,20 @@ static struct platform_device bcm2708_sp
 	.resource = bcm2708_spi_resources,
 };
 
+static struct mcp251x_platform_data mcp251x_info = {
+	.oscillator_frequency   = 16000000,
+	.board_specific_setup   = NULL,
+	.irq_flags              = IRQF_TRIGGER_FALLING,
+	.power_enable           = NULL,
+	.transceiver_enable     = NULL,
+};
+
 static struct spi_board_info bcm2708_spi_devices[] = {
 	{
-		.modalias = "spidev",
-		.max_speed_hz = 500000,
+		.modalias = "mcp2515",
+		.max_speed_hz = 10000000,
+		.platform_data = &mcp251x_info,
+		/* .irq = unknown , defined later thru bcm2708_mcp251x_init */
 		.bus_num = 0,
 		.chip_select = 0,
 		.mode = SPI_MODE_0,
@@ -595,6 +611,12 @@ static struct spi_board_info bcm2708_spi
 	}
 };
 
+static void __init bcm2708_mcp251x_init(void) {
+	bcm2708_spi_devices[0].irq = gpio_to_irq(MCP2515_CAN_INT_GPIO_PIN);
+	printk(KERN_INFO " BCM2708 mcp251x_init:  got IRQ %d for MCP2515\n", bcm2708_spi_devices[0].irq);
+	return;
+};
+
 static struct resource bcm2708_bsc0_resources[] = {
 	{
 		.start = BSC0_BASE,
@@ -723,6 +745,7 @@ void __init bcm2708_init(void)
 	system_serial_low = serial;
 
 #ifdef CONFIG_SPI
+	bcm2708_mcp251x_init();
 	spi_register_board_info(bcm2708_spi_devices,
 			ARRAY_SIZE(bcm2708_spi_devices));
 #endif

[msperl]

@Benoit: I just did a quick check on the SPI frequency with Overclocking turned on/off (and in active use) with my logic analyzer and I found that:
with 700MHz the SPI clock runs for me at around 61.69kHz (with 100KHz configured)
while running on 900MHz the SPI clock runs at 81.633kHz.

If you calculate the ratio then the SPI clock speed is raised with the core-clock speed (from 250MHz to 333MHz in my case).

I would expect the same "increase" to occur at higher configured frequencies, so as long as the MCP2515 is able to handle these higher SPI clock it should be fine.

The datasheet of the MCP2515 says on page 71 that the max allowed Fclk is 10MHz.

This means that you will need to "decrease" your max SPI clock (.max_speed_hz in arch/arm/mach-bcm2708/bcm2708.c) to accommodate for that increase in core frequency due to overclocking (worsted case to 5MHz to allow for TURBO speed which doubles core frequency and hence doubles SPI frequency as well)

I hope this answers your question...
Martin

[MurlocHolmes]

Has anyone evaluated the AMIS-30663 CAN Transceiver from ON Semiconductor? (http://www.onsemi.com/pub_link/Collater ... 0663-D.PDF)

It looks to be basically pin compatible with the MCP2551 but the RS pin has been replaced with a V33 pin that accepts 3.3V allowing the logic side of the chip to interface directly with 3.3V circuits. It still has a 5V Vcc input to drive the CAN physical side.

The 5V Vcc requirement looks to be about 50mA according to the data sheet.

It looks like the 3.3V load is around 170uA. Between the transciever and a MCP2515 SPI/CAN controller, it looks like the load on the 3.3V supply would be somewhere around 5.2mA, well under the 50mA spec on the Raspberry power pin.

Thoughts?

[msperl]

Thanks for the patch Bertr2d2!

One issue though - for me the system hangs on the network level when removing the fiq-fix-enable=1

This happens repeatedly!

Kernel messages look like this in /var/log/messages:

Code: Select all

Sep 24 12:00:57 raspberrypi kernel: [ 2162.699007] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000014
Sep 24 12:00:57 raspberrypi kernel: [ 2162.699040] smsc95xx 1-1.1:1.0: eth0: Failed to write HW_CFG_LRST_ bit in HW_CFG register, ret = -110
Sep 24 12:01:03 raspberrypi kernel: [ 2168.698508] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000014
Sep 24 12:01:03 raspberrypi kernel: [ 2168.698542] smsc95xx 1-1.1:1.0: eth0: Failed to write HW_CFG_LRST_ bit in HW_CFG register, ret = -110
Sep 24 12:01:09 raspberrypi kernel: [ 2174.698018] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000014
Sep 24 12:01:09 raspberrypi kernel: [ 2174.698052] smsc95xx 1-1.1:1.0: eth0: Failed to write HW_CFG_LRST_ bit in HW_CFG register, ret = -110
Sep 24 12:01:15 raspberrypi kernel: [ 2180.697517] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000014

I can reproduce this easily when working over the network - connection drops after some time

Martin

[Basti]

Hi all

First I want to thank all of you for your efforts with adding the mcp2515 to the Raspberry Pi.

I managed to add the necessary modules to my kernel and compile everthing.
But I have a problem to add a new CAN-interface with:

Code: Select all

ip link set can0 up type can bitrate 500000

i get an error message:

Code: Select all

Cannot find device "can0"

I've added all modules as mentioned in maddin's howto on page 3 of this thread.

lsmod shows correct modules loaded.

I can't figure out whats wrong with my setup.
I would be more than thankful for any help.

Greetings,
Basti

[bertr2d2]

Hi Basti,

Hi all
...
But I have a problem to add a new CAN-interface with:

Code: Select all

ip link set can0 up type can bitrate 500000

i get an error message:

Code: Select all

Cannot find device "can0"

Could you show the output from 'dmesg | egrep -i "can|spi|mcp"' and 'cat /proc/interrupts' ?

Regards
Gerd

[vlick]

Hi at all, I come back after quite a long period of absence, due to some family issues.

First of all, congratulations to all the guys for the very big steps I saw in interfacing the Can Controller MCP2515: I'll need some time to follow all the discussion and to be able to put in practise all the indications for having it running on the PI.

From my side, I finally received my PI some weeks ago and I started some activities: one of them was to interface a USB Can Controller to the PI, just for learning how to build a cross-comp tool chain for PI.
I choose to test some Kvaser USB Can Interfaces (which I bought in the past years for other projects): they are High Performance (and High Price...) devices but I decided to test them under Linux with the PI.
In the other projects, I used them with Windows based Operating Systems.
After some days of attempts, I was finally able to compile, to load the driver and to see the devices running on the PI: if someone is interested, I'll be glad to share my experience about it.
I'm aware that it is a very expensive solution to interface a Can Bus with PI, but using such a configuration the CPU load is quite low due to the high throughtput of HS USB bulk communication, leaving it free for other tasks.
As I said before, I'll try to arrange in the next week all the necessary to test the MCP2515, since I agree that this should be a good solution for the PI.

vlick

[msperl]

Hi Basti!

My guess is that the issue lies with /etc/modprobe.d/raspi-blacklist.conf, where you still have got the line: "blacklist spi-bcm2708".

Comment this line out and reboot (or reload all the modules) and then it should work...

Ciao, Martin

[Basti]

Hi all

First thing I did was, I uncommented the blacklisted modules and rebooted.
Reloaded all modules. Result is this:

dmesg | egrep -i "can|spi|mcp"

Code: Select all

[    0.000000] Linux version 3.2.27CAN_MCP251x_Moduled+ (root@raspberrypi) (gcc version 4.6.3 (Debian 4.6.3-8+rpi1) ) #5 PREEMPT Sat Sep 29 13:36:37 UTC 2012
[    0.076283] bcm2708_mcp251x_init: Entry
[    0.076300] could not obtain gpio for MCP251x CAN bus interrupt
[    1.873124] usb usb1: Manufacturer: Linux 3.2.27CAN_MCP251x_Moduled+ dwc_otg_hcd
[    4.901429] bcm2708_spi bcm2708_spi.0: SPI Controller at 0x20204000 (irq 80)
[    6.623507] CAN device driver interface
[    6.668550] mcp251x spi0.0: CANSTAT 0x80 CANCTRL 0x00
[    6.668576] mcp251x spi0.0: Probe failed
[    6.675340] mcp251x spi0.0: probe failed
[  141.990727] can: controller area network core (rev 20090105 abi 8)
[  145.451262] can: raw protocol (rev 20090105)
[  149.200869] can: broadcast manager protocol (rev 20090105 t)

cat /proc/interrupts:

Code: Select all

          CPU0
  3:      10009   ARMCTRL  BCM2708 Timer Tick
 32:     328834   ARMCTRL  dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb1
 52:          0   ARMCTRL  BCM2708 GPIO catchall handler
 65:        995   ARMCTRL  ARM Mailbox IRQ
 66:          1   ARMCTRL  VCHIQ doorbell
 75:          1   ARMCTRL
 77:       5492   ARMCTRL  bcm2708_sdhci (dma)
 79:          0   ARMCTRL  bcm2708_i2c.0, bcm2708_i2c.1
 80:        944   ARMCTRL  bcm2708_spi.0
 83:         20   ARMCTRL  uart-pl011
 84:       7666   ARMCTRL  mmc0
FIQ:              usb_fiq
Err:          0

lsmod:

Code: Select all

Module                  Size  Used by
can_bcm                11130  0
can_raw                 5798  0
can                    22877  2 can_raw,can_bcm
snd_bcm2835            12732  0
snd_pcm                75426  1 snd_bcm2835
snd_page_alloc          4987  1 snd_pcm
snd_seq                52584  0
snd_seq_device          6316  1 snd_seq
snd_timer              19642  2 snd_seq,snd_pcm
snd                    52567  5 snd_timer,snd_seq_device,snd_seq,snd_pcm,snd_bcm2835
mcp251x                 9059  0
can_dev                 8587  1 mcp251x
evdev                   8714  1
spi_bcm2708             4393  0
i2c_bcm2708             3462  0

My hardware setup for the CAN extension board looks like this:


I'm aware of the 20MHz crystal at the mcp2515 and have adapted that in the bcm2708.c-file.

But I'm not that sure about the correct pinning for the raspberry GPIO-connector and the correct pinning of the 74HC244

Thanks in advance for any advice!
Basti

[bertr2d2]

Hi,

Hi all

First thing I did was, I uncommented the blacklisted modules and rebooted.
Reloaded all modules. Result is this:
dmesg | egrep -i "can|spi|mcp"

Code: Select all

[    0.000000] Linux version 3.2.27CAN_MCP251x_Moduled+ (root@raspberrypi) (gcc version 4.6.3 (Debian 4.6.3-8+rpi1) ) #5 PREEMPT Sat Sep 29 13:36:37 UTC 2012
[    0.076283] bcm2708_mcp251x_init: Entry
[    0.076300] could not obtain gpio for MCP251x CAN bus interrupt

First problem here: you didn't get the GPIO and interrupt.

Code: Select all

[    1.873124] usb usb1: Manufacturer: Linux 3.2.27CAN_MCP251x_Moduled+ dwc_otg_hcd
[    4.901429] bcm2708_spi bcm2708_spi.0: SPI Controller at 0x20204000 (irq 80)
[    6.623507] CAN device driver interface
[    6.668550] mcp251x spi0.0: CANSTAT 0x80 CANCTRL 0x00
[    6.668576] mcp251x spi0.0: Probe failed
[    6.675340] mcp251x spi0.0: probe failed

Second problem: the MCP2515 didn't reset right - check your logic/connections. Regardless of the
INT pin this should work.

My hardware setup for the CAN extension board looks like this:

I can't get the reason why you want to use 74HC244 connecting the MCP2515 - the controller also
runs at 3V3. Please have a look at: http://lnxpps.de/rpie/

Regards
Gerd

[maddin1234]

Hi,
First, it looks like you swaped MISO and MOSI
MISO is "Master In Slave Out" and has to be connected to SO (Slave Out), ...

Second thing, why are you using CE1 when you have only one CAN controller?
Your system probes spi0.0, that is CE0.

Third thing, the voltage devider might be to "big".
I tried it with 22k series resistors in the spi signals to avoid damage of my raspi
when connecting to much voltage to the CANH and CANL (to limit current into raspi gpio),
but it didn't work. The rising or falling edge wasn't an edge anymore

[Basti]

Hello Gerd

Thanks for your advices.
I'm using a buffer because I want to use the setup for analysing my car's CAN bus. And because of the buffer I have built in ESD and overvaoltage protection for my Pi.

Yesterday I discovered that my HW-layout is faulty (output enable not grounded) and my mcp2515 is defective (14 ohms between Vdd and ground pin). Layout/board is fixed, replacement is ordered.

I will return and report when I have new information.

Thanks again for the help.

edit:
@Maddin: thanks for the tip. Will check that, too.

[bertr2d2]

Hello Gerd

Thanks for your advices.
I'm using a buffer because I want to use the setup for analysing my car's CAN bus. And because of the buffer I have built in ESD and overvaoltage protection for my Pi.

Probably you want CAN BUS Isolation. IMHO the best place is the CAN-Tranceiver to reach
your goal. The usual suspects offer them: TI ISO1050 , Analog Devices ADM3052, AD3053
(including DC-DC converter), ADM3054 and many others.

Regards Gerd

[bertr2d2]

Hi Benoit,

Hello,

Has anyone evaluated how the CAN MCP251x setup behaves on an overclocked Raspberry Pi? (refering to http://www.raspberrypi.org/archives/2008)

Setting the Core frequency to 333MHz shouldn't be a problem -> 333/32=10.4MHz - slightly above specs. I've connected a MCP2515 with 13.33MHz on a different platform. Just working fine. 500 MHz could be challenging - can't test it right now, I've borrowed my RPi to a colleague.

I've seen that your workaround avoiding duplicate CAN packets was accepted by the SocketCAN team. Congrats and thx

Regards

Gerd

[msperl]

Hi!

As for the mcp251x driver there is an issue of losing packets when running at 500MBit and with a CAN-bus Duty cycle of almost 50%.

The RPI starts to drop packets (and even more so when candump is running and printing to STDOUT)...

Right now the investigation between Gerd and myself include the observations that:

• RPI sometimes stops for longer periods of time (say 4.2ms) during which we loose 12-13 packets...
• we spend lots of time between MCPINTERRUPT low and the first ENABLE LO - in the range of 0.038ms
• we spend lots of time between SPI commands (ENABLE LO)- in the range of 0.030ms
• we spend lots of time between ENABLE LO and CLOCK run - in the range of 0.003ms
• we spend lots of time between CLOCK stop and ENABLE HI - in the range of 0.010ms

So we spend a lot of time waiting...

Also the way that the code looks to me, the driver seems to do all the SPI-communication while in the interrupt handler, which obviously slows down the RPI. So then those 4.2ms could be just a scheduled other interrupt or user process...

Gerd proposed some more tests (also with the asynchronous mcp2515 driver), which I will try to execute to see if this improves the situation and or we find out which layer is producing those latencies...

We will keep you posted,
Martin

[msperl]

I have now done some more testing and found that the mcp2515 driver is not using a threaded interrupt handler (like the in kernel mcp251x.c), but is working in the interrupt handler itself.
But it is making heavy use of asyncronous callbacks when a SPI command has finished, so it is quite quick and is not blocking the interrupts.

But unfortunately it is not much better at keeping up with the data - it still drops 13 frames from time to time.

As I read it the spi_bcm2708.c driver is based on a workqueue, which means it runs of a separate thread and all that the SPI command do is add their messages to the workqueue, which means a context switch to handle the SPI bus.
And as a thread it is susceptible to scheduling delays, which show up as those 4ms delays...

And as the "normal" mcp251x.c driver is also running as a thread, this would mean that there is an additional context-switch required to handle SPI.

I started now by contacting Chris Boot, who is the writer of the SPI driver for RPI to see what his opinion is.

Until then I fear we will need to accept this "packet-loss" or go for lower CAN speeds to reduce those overheads... (still at 125kHz, a typical (extended) CAN frame would take about 0.8ms, which is still smaller than the 4ms, that I typically see as those gaps)
The other option would be trying to drive SPI-Bus in the driver itself, which would be quite some effort and it is unclear if it would be of much more efficient.

Also it does not solve the overall latency issue that the SPI driver seems to face in its current incarnation, which may effect other devices that also need to use SPI with high frequencies...

Ciao,
Martin

[msperl]

Last thing on the "packet loss" side:

When running 100kHz there is no packet loss in my test setup.

Also the test runs with low CPU utilization:

Code: Select all

 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 0  0      0 143092  19836  39304    0    0    26     2  361   82  1  1 98  0
 0  0      0 143092  19836  39304    0    0     0     0  311   45  0  0 100  0
 0  0      0 143092  19836  39304    0    0     0     0  318   47  0  1 99  0
 0  0      0 143092  19836  39304    0    0     0     0  310   43  0  0 100  0
 0  0      0 143092  19836  39304    0    0     0     0  308   43  0  0 100  0
 1  0      0 142792  19836  39304    0    0     0     0  319   54  0  2 98  0
 0  0      0 143200  19836  39304    0    0     0     0 6238 3894 22 11 67  0
 1  0      0 143200  19836  39304    0    0     0     0 7914 11609  0 20 80  0
 0  0      0 143200  19836  39304    0    0     0     0 7223 10571  0 17 83  0
 0  0      0 143200  19836  39304    0    0     0     0  313   44  0  1 99  0
 0  0      0 143200  19836  39304    0    0     0    84  430   90  1  1 98  0
 0  0      0 143200  19836  39304    0    0     0     0  311   44  0  0 100  0
 0  0      0 143200  19836  39304    0    0     0    32  346   66  0  1 95  4
 0  0      0 143200  19836  39304    0    0     0     0  308   43  0  0 100  0

the low CPU usage (33% Load at 6000+ interrupts/s) is IMO OK...

The duty-cycle for CAN bus in this case is >90% (end of ACK bit to beginning of sync bit).

As soon as you reach 125kBit on the CAN bus those "gaps" start to appear...

For improvements on speed we will need to get a better/lower-latency SPI interface for linux it seems... - see also the discussion here:
http://gumstix.8.n6.nabble.com/Howto-ge ... 66254.html
where they came to the same observation...

Martin

[maddin1234]

Hi Martin,
what do you think about setting the scheduling to RoundRobin. (SCHED_RR)
As far as I remember, there you can set the maximum time a task will get, when
another task is waiting. (but I don't know what is the minimum)
Perhaps this will help, you might get more, but shorter gaps.

I tryed something similar in userspace here, before I started using the bcm2708-spi-driver:
https://groups.google.com/forum/?fromgr ... EPPhq4xqHk
https://groups.google.com/forum/?fromgr ... x88XJN0Rzo

maddin1234

[msperl]

There is a first version of a patch to the kernel driver available, that can improve the situation tremedously! There is not a single packet that gets lost on the driver level.

See here for the details: http://www.raspberrypi.org/phpBB3/viewt ... 44&t=19489

We still are facing a delay of about 0.027ms between the mcp2515 issues the interrupt and the time that the first SPI packet gets sent. This seems to be a Linux-immanent latency.

Still the overall time spent for a single packet on the SPI bus is 0.083ms. The time to the next Interrupt is 0.248 ms, so theoretically we could handle 2 more packets in that timeframe - and then we would come close to being able to handle a duty cycle of 80%. But this is very unlikely to happen, as there would be higher probability of collisions on the bus....

This is definitively an improvement.

But I have to tell you that (at least candump) is not receiving all the packets from the stack - there seems to be some CPU limitation on the CAN network stack all the way to the user-space programm, but this is definitively outside the scope... Maybe the CanSocket interface is more efficient in this respect - I have not tried it...

Ciao,
Martin

[Basti]

Hello together,

finally I hab some time over the week to investigate my circuit and the software/drivers. And I had the change to meassure the transmitted signals with an oscilloscope.
The results are as follows:

Yellow: SCLK-Signal from Buffer to MCP
Blue: MOSI-Signal from Buffer to MCP

Y_SCLK_MCP-B_MOSI_MCP.jpg (16.15 KiB) Viewed 15447 times

Yellow: MISO-Signal from MCP to Buffer
Blue: MOSI-Signal from Buffer to MCP

Y_MISO_MCP-B_MOSI_MCP.jpg (14.26 KiB) Viewed 15447 times

Yellow: MISO-Signal at RPi-GPIO ('between' voltage divider)
Blue: MOSI-Signal from Buffer to MCP

Y_MISO_RP-B_MOSI_MCP.jpg (14.61 KiB) Viewed 15447 times

Seems that Maddin's advice was 100% correct. The resistors I used for the voltage divider are far too large. The resulting current needs too much time to load and unload the capacity of the GPIO-connector.
I will try to correct that and give an update about the results.

Has anyone an idea about the voltage level the RPi needs to recognize a 'high' level?

Thanks again for all your advices.

Greetings,
Basti

[CCob]

Hi All,

Like many others, I am planning on creating a daughter board to interface with the RPi for communicating with a CAN network using the following schematic.

http://lnxpps.de/rpie/

I plan on interfacing with the CAN network running in my car. Do you think that the above schematic would suffice or should I modify it to isolate the CAN bus from the RPi?

Thanks.

[Basti]

Hi CCob

You can have a look here:
http://www.raspberrypi.org/phpBB3/viewt ... 27#p193527

I finished a first version of an extension board for the Raspberry to interface with a canbus.
It is not finally tested but should work.
If you like it you a free to use.

Thanks again for all the great help of the users in this thread!

Greetings,
Basti

[CCob]

Hi Basti, I'll take a look, thanks alot.