TIVA C-Ceries Launchpad to control 8 CANOpen Motors

Ivan Kuznetsov21 said:

2. If yes than do I need any additional devices (like tranciever for example)? Are there any special booster packs with CAN connectivity function?

Transceiver and an appropriate connector.  Considering the environment I'd suggest an isolated transceiver ( ISO1050 ?).  IIRC CANOpen defines a 24V line to power the isolated side.

I've not used SimmaSoftware so I can offer no opinion on that (and not any help on CANOpen itself either).

Robert

CANOpen protocol is a "rising tide" - yet not w/out some reported issues. (it remains difficult to find the "perfect" connection medium)

While you note, "8 such CANOpen Motors) may I suggest that you begin with just one - and add additional only - and if/when - you succeed w/that?

KISS always proves fastest, safest and "most likely to succeed" (while you're still young.) "All at once" - not so much.

CAN xcvrs are always required - and Robert's suggested device adds safety & robustness to your effort - makes very good sense.

Standard "trade mags" and CAN forum groups should give you a, "reading" into both CANOpen & SimmaSoftware - often worthwhile to "fact find" before "diving into deep water."

cb1- said:

While you note, "8 such CANOpen Motors) may I suggest that you begin with just one - and add additional only - and if/when - you succeed w/that?

Absolutely.

cb1- said:

(it remains difficult to find the "perfect" connection medium)

I've found Devicenet cable to be good.  Presently using Mid cable but if the power is just for transceivers then thin may be sufficient and it will be cheaper and easier to find.  In a pinch, for prototyping, I've used CAT-5 or rs-485 cable.

Robert

Hello Ivan,

Ivan Kuznetsov21 said:

1. In principle, is it possible to control them by EK-TM4C1294XL + SimmaSoftware CANOpen library?

Yes. But the licensing of the library you must be checking with Simma Software. They do support Tiva TM4Cx devices for the CANOpen ports

Regards

Amit

As others have said, in principle it is possible. However I shall question whether the TM4C129 is the right tool for the job. It depends on many things which you have not disclosed to us.
I'm involved in two projects where a communication system compliant with CANopen is used (just the PDO side of things, SDOs are not used) and there the Tivas (123 series) are slaves. The master is a BeagleBone Black, for which you can find plug-in CAN capes from multiple sources. The advantage of using a BBB instead of TM4C129 as the master is that controlling/modifying the master is an order of magnitude easier - you have pretty much all standard Linux software and a full networking stack available, hardly the case with TM4C129.

I've "liked" your post Veikko - yet might it be (bit) too "inside?"  

Speaking to, "orders of magnitude" might your post be made even more compelling with the addition of:

a) definition of PDO, SDO & capes - clearly not all here (perhaps many) share your expertise

b) case well made for Linux - yet as most here use another OS - does the "BBB" enjoy similar SW & "full networking stack" there - as well?

You're very much right - let's add some value:

cb1_mobile said:

a) definition of PDO, SDO & capes - clearly not all here (perhaps many) share your expertise

• PDO = Process Data Object; CANopen specifies 8 per node, 4 for transmitting and 4 for receiving data. Simply put a PDO is just a CAN message with a specific ID (CANopen node id + PDO id combined), each can transport max 8 bytes of data. The meaning of PDOs is device-specific and in a full CANopen implementation as far as I understand these are highly configurable.
• SDO = Service Data Object; again, just messages with "reserved" IDs. These are used for transmitting bigger chunks of data sequentially, usually device configuration settings etc. I've managed to do without so far, so I'm not going to try to explain any further.
• Cape = An add-on board for the BeagleBone series of minicomputers. Just a fancy/funny name, like shields for Arduinos, BoosterPacks for LaunchPads etc etc

cb1_mobile said:

b) case well made for Linux - yet as most here use another OS - does the "BBB" enjoy similar SW & "full networking stack" there - as well?

I looked and it looks like some form of Windows Embedded has been ported to run on the BBB, but my experience on Windows Embedded is nil. Community engagement for the BBB heavily concentrates on different flavours of Linux, therefore I think of it as a Linux computer. A similar product, the Raspberry Pi 2. certainly has Windows support but lacks a CAN interface. Of course if one wishes to use a Windows computer, there are a lot to choose from - just add a CAN interface (there are a lot of USB based ones, too) and off you go.

But this is all guesswork - we've got no clue what the requirements for Ivan's project are. My main message is to re-evaluate whether the chosen tool is the right one - it might very well be, or totally not!

Veikko Immonen said:

You're very much right

Said/aimed towards cb1 - that's a rarity...   But....thank you....thank you very much.   (in the register of past, famed, dead, singer/entertainer)

Terrific - now your initial writing is far more, "warm/fuzzy" and may just spur others to, "Right (i.e. best/brightest) Tool for the (well defined) Job..."

"Wheels up" in minutes as we - once again - hope to overfly pesky mountain.   Great job here, Veikko - thank you...

Hi Robert, thank you for your answer. What do you mean by:

Robert Adsett said:

 IIRC CANOpen defines a 24V line to power the isolated side.

Could you please give me some referencies? I read   CIA102 and CIA301 and don't find anything about 24v there.

Thank you!

Thanks Veikko,

I were thinking about something like BeagleBone or any linux based devices but the problem is that we need a real-time controlling device which is pretty hard to achieve with linux as an os.

Hi everyone! Thank you very much to all. To be honest I didn't expect such an active and helpful community.

I have decided to make some very simple tests and choosing the simpliest possible tranciever for it. As far as I have understood, to avoid the neccesarity of additional power supply I need the 3.3V tranciever. Is it correct? The next question is can I supply this tranciever directly from the Launchpad from 3.3v pins?

See e.g. www.interfacebus.com/Can_Bus_Connector_Pinout.html

Note the CAN V+. It's been a while since I reviewed but as I recall there was only specified to be enough power to run the isolated side of the transceivers.

Something like an ISO1050, a linear supply and a handful of passives makes a nice simple isolated connection. You can build your own with separate isolator and CAN transceiver but I've found that the isolated CAN transceivers match or exceed the build your own in terms of delay (which is vital for CAN), and they are a lot simpler to design in.

Robert

Keep open the option, at least in initial design work, of splitting the task.  Move the hard real time to something like a TIVA (ie running path profiles) and keep soft real time and non-real time to something like a BBB (ie path planning)

Also there are real time Linux extensions.  I've no experience in them but they appear to be used and maybe someone in the BBB community has.

Robert

Friend Robert - per usual - comforts while raising the flag of, "isolation." 

You've asked if you may "steal" power from L-Pad - would not your review of the L-Pad's 3V3 regulator spec - and calculation of CAN Xcvr's demand - best answer?

You're silent as regards the separation and powering of your remote, CAN controlled Motor.    As Robert's post suggests - isolating that (expected) noisy motor power supply from your MCU board so often proves worthwhile - sometimes even mandatory.

Our experience is that your ability to, "Establish robust CAN "bi-di" communication" - with your remote CAN device - should be, "First order of business."    Only after that's up/running - test/verified - should the motor be engaged.

As always - KISS rules.   And KISS + isolation - so much the better.     Giving your MCU (local & remote) the "best chance to succeed" often works "wonders."