CANbus consultant?

Before everyone on this newsgroup forms an orderly queue, a few more details from your direction would help.

What sort of system are you looking for (in terms of the type of process, inputs, outputs etc), what sort of environment, where you are located and whether you feel you need consultancy from someone who is geographically close.

--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

It's pretty much a monitoring circuit. It needs to monitor some voltages and current and report faults. Also, it needs to be able to turn on and off a circuit. Probably the most difficult part is that is needs to be field reprogrammable. It will need to operate in the temperature range -40°C to

+85°C.

We currently have a working design but it uses RS-485 instead of the CANbus interface. We have a guy in-house that typically does these designs but my boss is looking for someone outside. I think our internal guy is too over booked for this project, I think. Actually, all I really know is that my boss asked me to find someone able to do this project. I don't see a problem in handing over the current design.

I don't know if my boss cares if the help comes from someone local or not. We are located in Salisbury, MD, USA.

What protocol are you putting on top of your CAN bus? CANopen? J1939? Home-brewed?

Do you mean field reprogramable via CAN?

Do you know that your email address is broken, so it's hard to find the head of the queue, orderly or not?

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html

 >> Mike King wrote:  >>  >>> Where should someone look for a CANbus consultant?  We have a need for  >>> a CANbus design and the corresponding programming.  

Lets deal with this reprogrammability issue first and foremost. How much reprogrammability is required. The choice is:-

  1. Adjustment of Parameter Variables (Alarm trip levels, process       set-points etc).   2. Limited Reprogramming of functions (to incorporate new methods        of operation).   3. Full code down-load.

Programmability to style 1 is quite easy to achieve on CANBus connected systems. Style 2 is  more difficult but if the code block size under change is of limited size then it may be accomplished easily enough (PLC style change of functions). Style 3 is not really suitable on CANBus systems.

There may be some ready made sensor units for these functions. Might be worth doing some searches for them. I would need more specific detail from you to find something suitable.

Not too arduous but will require some careful selection of components.  

 

Do you have a full spec of the system? I would have to look it over to see if I can see a way of fitting it in with my schedules. I am in the UK (as you may have already figured). Like Tim, I found your email address to be broken and have tried variations on a theme to try to email you directly.

--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

Full code down-loads are done at least with some CanOpen devices, but in practice requires a low load and low noise bus.

In the segmented SDO transfer 7 net bytes can be transferred in each frame. Since each frame is acknowledged, it can be hard to transfer more than about 1 kbyte/s due to the latencies at both end, so the download time can be minutes.

In block transfer, up to 127 frames can be sent before acknowledged, each carrying a 7 byte payload. Theoretically up to 30-50 kbytes/s could be transferred at 1 Mbit/s on an empty bus. I would only use block transfer with Philips SJA1000 style controllers with hardware FIFO, since the interrupt latency requirements on Intel style CAN controllers would be extremely demanding with slow processors.

Paul

-- snip --

One of my clients is fielding a system that has full code download on CAN. It works fine.

If this were a requirement you'd want to pick your higher-level protocol carefully -- we rolled our own on that project; you'd want to make sure that you had one simple enough that the boot code didn't get huge.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html

I know of a system (still in production AFAIK) that does 3 on every power up. It's an electric vehicle so it does that fairly frequently. It takes long enough that it was eliminated in the next design but it was not sufficiently annoying to prevent it from going into production for years.

For an occaisional field upgrade I don't see that this would be an issue. I wouldn't want to to a huge download that way but I don't really expect that's likely to be an issue.

Robert

--
Posted via a free Usenet account from http://www.teranews.com

[...] [...]

Yet that's a routine requirement in the automotive sector. Care to explain what's so unsuitable about it?

CAN is no harder to use, nor less suitable for the connection over which to send a fresh code image than any other data link would be. I'd say its builtin resilience against data corruption actually makes it a considerably better choice than any average home-grown protocol over a RS232, RS422 or RS485 line could hope to be.

Also done sometimes in industrial applications.

Without doing any actual calculations, I would expect that 15 bit CRC with 8 net payload bytes is better than 16 bit CRC with 256 byte payload (e.g. Modbus), so indeed it helps using short frames.

However, if looking at total throughput, the CAN is quite problematic.

But of course rare program updates can be done using the CAN interface with a laptop, however, doing the same download using a large bus running in a actual real-time production environment might be problematic.

Paul

h=20

The primary intention of CAN is send-and-forget network. Yes, there are=20 the connection oriented modes of operation, like TP, for example.=20 However those are the special modes which should be used on the special=20 cases.

The complexity is not in the CAN itself, but in the protocol stack which =

has to run over CAN. If there is a need to be compliant with J1939 or=20 some other protocol, that will take quite a lot of software work. The=20 whole point of using CAN is to be compliant with the hardware/software=20 of the other parties. If there is no such goal, a home-grown protocol=20 over RS-232 or similar is the way to go.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

This is not really important. There should be no data errors under the normal operating conditions in the either case. And the either variant will detect the occasional data failures with the high enough probability.

Exactly. Moreover, for the normal operation, the CAN bus should not be utilized over 30% of bandwidth.

The reflashing is a special mode of operation anyway. The whole network should be put into this mode.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

With dozens of nodes with their branches, the electric network may be quite problematic, also if slip rings are used, the bit/block error rate can be quite high.

I would prefer to detect the transmission error immediately and not after five years, when a rarely used (and corrupted) code branch is actually executed :-).

This is definitely a good advice for CSMA/CD 10base2/5 ethernet or master/slave RS-485 protocols, but I would tolerate a 50-60 % usage on CANbus devices due to the low cost of collision.

While this is the preferred mode of operations, there are situations, in which you can not take down the bus this year (perhaps next time in

2010 :-) or you can not send a technician with a laptop to the device, disconnect the device from the bus, flash the device and reconnect the device, due to occupational health issues (even with protective gear).

The reason for using CAN devices in harsh industrial environments is that a large number of devices were originally developed for the harsh automobile and engine (J1939) industry.

Paul

I am working for the automotive. It is required not to have any broken data. Every error frame or a packet not at the right time is the issue. Although the network is required to tolerate the certain amount of errors.

If the CAN bus is utilized for more then 30% of the bandwidth, there would be a significant degradation of the real time performance.

Of course there is no need to disconnect the device from CAN to reflash it. The whole network is set into the diagnostic or maintenance mode, and then the tech can do whatever is required.

How do you like the idea of reflashing, say, a transmission control module, while you are driving a car? :)

I don't think CAN is a very good idea for the industrial type of applications. The initial meaning of the CAN abbreviation is "Closed area network", they changed it to "Controlled area network" later.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

This would be the case in practically any other bus, but not in CAN.

It is perfectly OK to run low priority messages (e.g. diagnostics) up to 100 % bus loading, without sacrifying the real time performance of high priority messages, due to the hardware arbitration.

Unfortunately there might not be any such opportunities this decade.

No problem with that, however I would not want anyone to update the breaking system when doing a emergency breaking or driving on a icy road (which is of course a standard skill here up North every winter for several months).

In the US the DeviceNet specification is built on CANbus, in Europe the CanOpen is dominant for industrial applications. At least a few hundred CanOpen nodes can be used on 4-6 busses on an area of a few football fields (whatever that area unit commonly used in US media is exactly) to do quite complex tricks :-).

Paul

What's the difference? If you are reflashing while performing normal ops, two flash devices must be used since you can not execute code in a flash device while reflashing the same device. So, the second device gets programmed while the first is being used for code execution. After successful reprogramming, the second device is used for code execution on the next cold start.

~Dave~

The point that I am trying to make is that the reflashing over CAN has to be a special mode of operation of the whole CAN network anyway. The functionality is limited in this mode. There is no regular traffic in this mode, so the bulk transfer can occupy the full bandwidth.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

With the hardware arbitration or without it, the expected latency has the exponential dependence from the bus load. And at the 30% load, there is an abrupt increase in the latency. Also, at the higher loads, there is a significant probability of the flood on CAN.

I see. We are talking about the different areas of the application with the different requirements: the industrial and the automotive.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

Thanks for all of your responses. Late Friday, I assumed this thread went cold. Sorry for the invalid email address. I haven't put a valid email address in the headers because of spammers. My email is mking AT klmicrowave DOT com.

Yes, the device needs to be field reprogrammable through the CANbus interface. The customer has written a spec for their protocol (yes, home-grown). Listed below is from the table of contents from the customer?s spec. This is the portion of the spec that the customer is requiring us to implement. The entire spec describes their CAN protocol for the entire basestation not just the LNA that we are providing.

4 Message Definitions 21 4.1 Software Download Messages 23 4.1.1 Software Download Process 23 4.1.2 Software Download State 24 4.1.3 Software Download Image First/More/Last 25 4.1.4 Software Download Image Stop 26 4.1.5 Verify Software Image 27 4.1.6 Activate Software Image 28 4.1.7 Update Boot Image 29 4.2.2 Enable/Disable RF 32 4.3 Version Information Messages 33 4.3.1 Read Vendor Id 33 4.3.2 Read Model 34 4.3.3 Read Serial Number 35 4.3.4 Read Hardware Version 36 4.3.5 Read Bootloader Version 37 4.3.6 Read Software Version 38 4.3.7 Read RF Band 39 4.6 Monitoring Messages 43 4.6.1 Summary Status 43 4.7 Alarm control Messages 44 4.7.1 Summary Status 44 4.7.2 Inform Messages Priority 45 4.7.3 Alarm Messages Priority 46 4.8 Time Control Messages 47 4.8.1 Read/Write Time 47 4.9 Debugging Messages 49 4.9.1 Enable Debug Mode 49 4.10 Autonomous Messages 52 6 LNA Message Definitions 87 6.1 Control Messages 88 6.1.1 LNA Bypass 88 6.1.2 TTLNA Mode 89 6.2 Configuration Messages 90 6.2.1 LNA Read/Write Central Frequency 90 6.2.2 LNA Filter Configuration 91 6.2.3 LNA Bandwidth 92 6.3 Monitoring Messages 93 6.3.1 LNA Read Status 93 6.3.2 LNA Read Calibration Gain 94 6.3.3 LNA Read Device Current(s) 95 6.3.4 TTLNA Read Calibration Gain 96 6.3.5 TTLNA Read Device Current(s) 97 6.4 Alarm Control Messages 98 6.4.1 LNA Alarms and Transitioning 98 6.4.2 LNA Alarm Declaration and Clearing 99 6.4.2.1 LNA Alarm Declaration Threshold (X) 99 6.4.2.2 LNA Alarm Clearing Threshold (Y) 99 6.4.3 LNA Read DC Power Alarm 100 6.4.4 LNA DC Power Alarm Clear Threshold 101 6.4.5 LNA DC Power Alarm Declare Threshold 102 6.4.6 Enable LNA DC Power Alarm Report 103 6.4.7 TTLNA Read DC Power Alarm 104 6.4.8 TTLNA DC Power Alarm Clear Threshold 105 6.4.9 TTLNA DC Power Alarm Declare Threshold 106 6.4.10 Enable TTLNA DC Power Alarm Report 107 6.5 Debugging Messages 108 6.5.1 LNA Force Alarm Conditions 108 6.6 Autonomous Messages 109

The reason I said that style 3 was unsuitable on CANBus is because a full code download would, necessarily, occupy a very significant proportion of time and in many situations the time for re-downloading a full application to a node would be quite prohibitively long. Others have mentioned that a full network shutdown may be decades away. If it has to be done I am certain that there would be solutions but in a High Integrity Application I would definitely be looking very closely at the hazards involved very carefully. Better would be to keep with style 1 and/or 2 if at all possible.

--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************