Activity for Janez
-
Janez posted a comment on discussion Open Discussion
Yes, application can define and and initialize it to add additional functionality or override default read/write callbacks.
-
In CANopenNode V4 (latest on github) you could specify a custom callback function for reading and for writing any OD entry. SDOs and PDOs use those callbacks. That way you can access any external library, own way. You would then probably use CANopenNode for all CANopen communication.
-
https://github.com/CANopenNode/CANopenNode https://github.com/CANopenNode/CanOpenSTM32/ https://github.com/CANopenNode/CanOpenEditor
-
You are probably right. Here are my tests with Linux and PIC32: https://github.com/CANopenNode/CANopenDemo/blob/master/test/test_report.md#sdo-transfer-test-reports-for-different-target-systems If you use Linux, you could test STM32 as demoDevice the same way. Segmented transfer should work in all cases, for block transfer you need a good CAN interface. But I think, XXAT is not supported on Linux.
-
Maybe you can check: https://github.com/CANopenNode/CANopenDemo/blob/master/tutorial/README.md Or some other documentation about CANopen SDO.
-
I didn't try, but it should be possible. See CO_ODinterface(). The only function which uses object dictionary is OD_find(). It returns pointer to OD_entry_t object, if found. Please note, entries must be ordered by index for this function to work. Files CANopen.c and CANopen.h are complex because of flexibility and ability to integrate OD.h and OD.c files. For most custom solution you could also write own CANopen.h/c files and generate object dictionary dynamically without OD.h/.c files.
-
This is an old page, don't know, why it is still there. Please see: https://canopennode.github.io/ https://canopennode.github.io/CANopenLinux/index.html
-
https://github.com/CANopenNode/CANopenLinux#can-interfaces
-
It is CAN FD ready to some degree. I don't know, if somebody implemented driver for CAN FD support. PDO is CAN FD ready, but not tested. USDO is not implemented. See also here: https://github.com/CANopenNode/CANopenNode/issues/342
-
This is from ChatGPT: what is simple bootup in canopen In CANopen, the "boot-up" process refers to the initialization process that takes place when a node is powered on or reset. During this process, the node runs through a series of checks and configurations to ensure that it is operating correctly and can communicate with other nodes on the network. The "simple boot-up" process in CANopen is a simplified version of the boot-up process that can be used in certain applications where a more comprehensive...
-
This is from ChatGPT: In CANopen, the "boot-up" process refers to the initialization process that takes place when a node is powered on or reset. During this process, the node runs through a series of checks and configurations to ensure that it is operating correctly and can communicate with other nodes on the network. The "simple boot-up" process in CANopen is a simplified version of the boot-up process that can be used in certain applications where a more comprehensive initialization process is...
-
Hi, As I know, something like this is specified in standard CiA302, object 0x1F80 - NMT Startup. Here is an excerpt: bit 0: 0(1) - device is not (is) NMT master bit 1: 0(1) - if bit3=0, start explicitly assigned (all) nodes bit 2: 0(1) - automaticaly enter (DO NOT automaticaly enter) the operational state on bootup bit 3: 0(1) - NMT master may (may not) start nodes automatically bit 4: 0(1) - if monitored node fails heartbeat handle that (all) node(s) bit 5: 0(1) - flying master process not (yes)...
-
I think, there is no problem, if you add the define in the CanopenEditor.
-
I used those defines mostly in application programs. But I'm afraid, there is missing information about index. I actually never needed that information.
-
Hi Janez, is there any way to send you a PN? You mean private note? I think, it is possible on Sourceforge, but you can also send email directly (available from my commits)
-
I think, there is no special rule about that. COB_IDs for first 4 PDOs are just pre-defined. System integrator is responsible to configure PDO communication correctly. I think, it is no problem to use COB_IDs of another node-id, just make sure your devices won't collide.
-
I agree. Maybe "TX PDO Mapping" and "TX PDO Mapping" tabs could just be temporary disabled, to avoid confusion. For now, I don't think, it is necessary to make deeper changes. The program works quite well for my case (new version). I think some minor fixes and updates are enough. I will try to be online on https://github.com/CANopenNode/CANopenEditor/issues for questions from now on. I sent you the invite from Github. Thank you.
-
Hello, it seems, I totally missed the CANopenEditor project. Sorry for that. I turned on watch on the project now. If I understand it correctly it is checked if e.g. CO_TPDOMapPar_t have the same size as OD_TPDOMappingParameter_t. Or in other words: If the number of mapped objects in the object directory corresponds to the number of mapped objects in the stack. You are correct. V1.3 has those limitations. It is very important, Object dictionary is specified correctly. I'm not sure about the fix from...
-
CANopenLinux/canopend may be a good starting point. Just compile and run it as described in https://github.com/CANopenNode/CANopenDemo/blob/master/tutorial/README.md You can use cocomm to read/write your controller: cocomm "<node-id-of-your-controller> read 0x1017 0 u16" You can write a bash script to configure all parameters, including PDO mapping and communication. You can also create own CANopen Linux device and add own program as demonstrated in https://github.com/CANopenNode/CANopenDemo/tree/master/demo...
-
It seems driver on consumer works fine. Are you sure, your RPDO consumer is operational. Did you turn on heartbeat (object 1017)? You can disable eeprom and use latest version, it works fine on Max32.
-
As you describe, everything is correct. Maybe is something wrong with the driver. Can you test with devices from https://github.com/CANopenNode/CANopenDemo ?
-
The CAN message with ID=0x181 is a TPDO from the produces side. The same message is named RPDO from consumer side. In your case that PDO should be consumed by your "consumer" device. And the only thing visible on the consumer device is value of 'Write_digital_output_8_bit[0]'. And your "consumer" device must be operational, of course.
-
COBIDs are correct But your TPDO is two bytes long and your RPDO maps only one byte. You can use dummy mapping in RPDO. Set OD_Entry(1600,0x02) = 0x00020008 OD_Entry(1600,0x00) = 2
-
PDO is producer - consumers, not master - slave. Can you show your RPDO configuration.
-
For PDO you have to configure TPDO on remote device and RPDO on your "master", for each remote TPDO. Dynamic PDO mapping enables this in run-time. See also https://canopennode.github.io/index.html
-
SDO block transfer transfers data in multiple sub-blocks. Each sub-block is a sequence of several CAN messages and is confirmed. After confirmation new sub-block is started with sequence number 1. If there was error in previous sub-block, then part of data is re-transmitted in next sub-block, but sequence number always starts with 1. There already was some misunderstanding, see here: https://github.com/CANopenNode/CANopenNode/issues/205#issuecomment-652955017 As I know, SDO block transfer works correctly...
-
Would this be possible following the structure of "CO_driver_blank.c", but just adjusting it to STM32 using HAL Of course, it is possible. SDO client is advanced feature, it is hard. It may be better to use available tools. SDO server is part of the stack, it works without interaction of the application. SYNC is configurable by OD parameters. Application usually reads/writes to OD variables or provides read/write functions for them. SDO client (external device/tool/canopend-by-CANopenNode/CANopen-for-Phyton)...
-
Actually application does not need to communicate with the driver. It is enough, if it accesses variables from the object dictionary. CANopen has everything needed for exchanging variables from object dictionary between multiple devices in CANopen network. SDO or PDO communication.
-
Please see here: https://github.com/CANopenNode/CANopenNode/issues/270
-
There is actually just a development in the last year. The newest is newOD, which was quite rewritten and will soon be finished. It is quite compatible with previous versions. It will become a master branch. Current master will be renamed to v2.0master and is rewritten to half (old object dictionary). v1.3 is previous version. For all new designs latest version is recommended. Older versions are still maintained to some degree for people, who still use them. Some information is in doc/CHANGELOG.md...
-
Please see some discussion here: https://github.com/CANopenNode/CANopenNode/issues/239
-
I think, MAX32 should work out of the box, if you just open project https://github.com/CANopenNode/CANopenPIC/tree/master/example_PIC32_ex16_IO.X Check for eeprom connection in file: https://github.com/CANopenNode/CANopenPIC/blob/master/PIC32/eeprom.c Then enable eeprom: project properties -> xc32-gcc -> Preprocessing and ... -> Preprocessor macros -> add -> USE_EEPROM
-
Hi Asma, First thing, CANopen is little-endian, so you have to swap multibyte values. So error code is 0x6100. See CO_emergency.h for information. Emergency is "0x60xx, Device Software". Third byte is error register. Fourth byte is from CO_EM_errorStatusBits_t, in your case "0x29, generic, critical, Timer task has overflowed". Search for "CO_EM_ISR_TIMER_OVERFLOW" inside source code. You probably have some long functions inside timer interrupt, which is meant to be for realtime, fast execution. You...
-
I'm not sure, if storing works on explorer16 board. However, it works on my board, connection is in attachment.
-
I have MAX32 board, but I didn't test it yet. Previously I was testing on Explorer16 board with the same PIC. Can you specify which network shield do you use and how is eeprom connected. It should be connected to SPI2A. Check eeprom.c file.
-
Yes, by default 1017 should be stored. Can you share some details about your hardware?
-
I will update the readme.
-
There was some conversation with author of Object Dictionary Editor Please see here for further information https://github.com/robincornelius/libedssharp
-
Yes, I think, this may work.
-
No this is not possible in the current version. But there is coming a new version, with new Object Dictionary interface, where this will be possible. See https://github.com/CANopenNode/CANopenNode/issues/162#issuecomment-751724920
-
Those default COB-IDs are only a suggestion. I think, they are used only in master-slave configuration. COB-IDs are free to assign. I usually use default COB-IDs only for TPDOs and configure RPDO COB-IDs to match those I need.
-
I have not tested multiple clients. But I think, principle you describe should work. CO_SDOclient_setup() setups specific CO_SDOclient_t object and setups also CAN receive and transmit buffers and also (hardware) CAN receive filter, associated with that object. So each SDO client has own object an also own CAN buffers and filters, so it is independent. You don't need to call CO_SDOclient_setup() again, if CAN identifiers for that SDO client didn't change.
-
Discussions are here: https://github.com/CANopenNode/CANopenNode/pull/219#issuecomment-725981796 I think, you are on the right track.
-
I think, it is.
-
NMT master messages must be seen. Bootup message is the same as heartbeat, but data is 00. If there is some problem in the device, one emergency message will follow just after it. You can send NMT commands also from RPI CANopen command interface.
-
Don't understand the question. Can you share some output from candump. Bootup messages should be visible.
-
If the arguments to this function are the same, then it is not necessary to call the function. For the details see code inside CO_SDOclient.c
-
This are more advanced topics. You will have to understand PDO communication and mapping parameters and how to configure them. PDOs are usually exchanged between two or more devices, cangen is just a simulator, example here, useless otherwise. I'm giving you the same advice as I gave here: https://github.com/CANopenNode/CANopenNode/issues/244#issuecomment-732763084 I can not explain all the details, other sources are much better.
-
They are independent variables. OD_writeOutput8Bit[0] (leds) are digital outputs on PIC and OD_readInput8Bit[0] (buttons) are digital inputs on pic. Different signals.
-
leds = OD_writeOutput8Bit[0]; "OD_writeOutput8Bit" is OD variable. It is mapped to first RPDO. You can access it via SDO also. OD_readInput8Bit[0] = buttons; "OD_readInput8Bit" is different OD variable. It is mapped to first TPDO. You can access it via SDO also.
-
There are many different information on pictures, it is hard to comment. First note: - 730 05 means: 730 is heartbeat from PIC, 703 is RPI, 05 means operational, 7F means pre-operational - messages from canopend shows operational state for RPI - For PIC to accept or send PDOs, 730 must be 05 leds and buttons are two very different variables.
-
You are making a mistake, you should use canopencomm in own terminal. But, don't use canopencomm, use canopend from latest canopennode, it is simpler. Just follow my previous instructions.
-
Hi Eng, Everything you have is just perfect for now. You have reliable CAN connection between PIC and RPI. Oscillator is fine. Now just stop using vcan0. It is virtual, it works only inside Linux kernel, you can't connect PIC to it, it is useful only, if you have no real CAN devices. So just forget it, because now you have real CAN network, can0. On can0.png, candump shows heartbeat messages of two CANopen devices. One is PIC and one is RPI. RPI is operational and PIC is not. Both are equal, no master/slave...
-
You can run candump can0 in another window. Can you show some output. Can you also show canopend window. What you type and what is the response.
-
can0 and vcan0 are two different linux CAN devices. use the same device as in candump: ./canopend can0 -i1 -c "stdio"
-
can0 and vcan0 are two different linux CAN devices. use the same device as in candump: /canopend can0 -i1 -c "stdio"
-
PIC32 has quite complex frequency settings. Make sure, you correctly understand all of them. 200000 seems strange to me. Also make sure, you are not mixing CAN and CAN FD.
-
Please see the datasheet (CAN section)
-
Until you are expert for Linux and CANopen, any question may seems trivial :) Linux can have many CAN interfaces, real or virtual. Virtual CAN interface mean, it is not connected to any hardware, it is just internal software device. Not usable, if you need to test your PIC. So just forget virtual CAN. You activate your real CAN hardware device with (in Linux CAN is network device, similar as Ethernet): sudo ip link set up can0 type can bitrate 250000 You can display information about running network...
-
Until you are expert for Linux and CANopen, any question may seems trivial :) Linux can have many CAN interfaces, real or virtual. Virtual CAN interface mean, it is not connected to any hardware, it is just internal software device. not usable, if you need to test your PIC. So just forget virtual CAN. You activate your real CAN hardware device with (in Linux CAN is network device, similar as Ethernet): sudo ip link set up can0 type can bitrate 250000 You can display information about running network...
-
No. I said, you can use candump, to first see bootup and heartbeats and solve your MHz problems. I usually use rasbberry pi with pure Linux on it. In respect to canopennode it does not differ from PC with Linux.
-
I don't understand the question.
-
In Max32 schematic there is 8Mhz crystal, as I can see. But PIC32 has additional configuration settings, so it can reach higher cycles. You should take care of the settings of configuration bits. You can use candump in raspberry pi and nothing else. You should see bootup and heartbeat messages from PIC. However, establishing CAN communication for the first time may be challenging. If there are some changes needed in the CANopenPic code, please let me know.
-
For now it may be easiest, if you just comment CO_errorReport() function call inside CO_HBconsumer.c. In the upcomming release emergency processing will be more configurable.
-
Just open the project "example_PIC32_ex16_IO.X" and compile.
-
You have some problems with projects settings, files, directories? Please strictly follow the https://github.com/CANopenNode/CANopenPIC This should compile properly.
-
0x85 = 0x80|0x04|0x01
-
You have to use OD editor to generate CO_OD.h/c files. see https://github.com/CANopenNode/CANopenNode#object-dictionary-editor
-
See CO_SDO_OD_attributes_t in CO_SDOserver.h
-
There are books explaining CANopen. I willl try to explain PDO linking on short: There is one device (suppose it has Node-ID equal to 0x10), which wants to share own data with other device(s ). Configure first TPDO COB-ID to ( 0x180 + Node_Id_10) = 0x190(default) . Then configure another receiving device (or more devices, if necessary) to accept PDO with that COB_ID. For example, configure first RPDO on device 0x20 with COB_ID = 0x190. You don't have to use default values.
-
You can use SDO client on one node and configure others. See 309/CO_gateway_ascii.c for example usage.
-
Yes
-
It is not separated, but you can use separately. CANopen is not master/slave protocolol anyway.
-
CANopenNode can also run on simple microcontroller. For example simple CANopen capable sensor, which has multiple parameters configurable. Parameters are ordered in Object Dictionary. SDO server enables access of any own parameter to external CANopen configuration device. Some parameters can be configured for transfer with no protocol overhead (see PDO). There are usually multiple "simple" CANopen devices communicating over CANopen network. They usually exchange PDO-s between themselves. Linux example...
-
You are talking about CAN. But CANopen is something else, it is higher level protocol build on top of CAN. CANopen is widely used in industrial automation and similar. There are books, which explain CANopen. For basic explanation see README.md file. If you just need CAN in Linux, then you may read the Linux kernel documentation: https://www.kernel.org/doc/html/latest/networking/can.html
-
It is easiest, if you look into socketCAN/CO_main_basic.c and seek for #ifdef CO_USE_APPLICATION app_ ...(); #endif You can insert your code via functions there. Otherwise make your custom main.c file...
-
If you are not able to send any CAN message, then there may be problem with driver, CAN settings, bitrate, CAN wiring, CAN terminating resistors or else.
-
CANopen.c is for most common usage. You can edit it, if you like.
-
I just changed that function in the latest release of CANopenNode, please see there.
-
Hi, NMT slave is mandatory by CANopen standard, but technically it is not necessary. I have a plan for CANOpenNode to be fully configurable and also to rewrite SDO server and OD part of it. For now you could manually remove all un-neded parts, but you will still need a driver. If you have enough RAM it may be easier, if you just use it as is. It does not consume much processing power. Other CANopen services are also quite useful for communication.
-
Please forget about master and slaves. There are individual CANopen nodes and PDO is producer consumer(s) protocol. (See https://www.can-cia.org/can-knowledge/canopen/pdo-protocol/) There are books for CANopen, you get best understanding, if you read one. However, CANopen is not so hard to understand in it is quite logical. But your question is too wide and has many missing details, I can't answer you. Did you go through https://github.com/CANopenNode/CANopenNode/blob/master/doc/gettingStarted.md...
-
You don't need to know the internals of the stack code. You only have to populate OD variables with your data and map those variables to (T)PDO on the other device map the same (R)PDO to some OD variables. Please read also here: https://sourceforge.net/p/canopennode/discussion/387151/thread/4f7b35c805/ or https://www.canopenbook.com/
-
Yes, something like that. Please read more about PDOs in book or somewhere.
-
You must not use CAN FD. Try lower bit rate.
-
Can you show some more info about your error and candump output? Don't use CANopenSocket, it is outdated. Use CANopenNode only, just as described in new Getting started. You can edit CO_main_basic.c as you say. I answered also here: https://sourceforge.net/p/canopennode/discussion/387151/thread/6645c5fc/ You can't interact the data with OD editor, it is just editor.
-
https://github.com/CANopenNode/CANopenPIC/blob/master/example_PIC32_ex16_IO.X/appl_PIC32_explorer16_IO.c uint8_t leds = OD_writeOutput8Bit[0]; switch leds .... read buttons..... OD_readInput8Bit[0] = buttons; OD_writeOutput8Bit and OD_readInput8Bit commands can be accessed with SDO read or write commands. Both can optionally be mapped to PDO, so communication betwen nodes is automatic.
-
You have a realy basic questions and you have some misunderstanding. I guess, you are trying to establish a real CANopen connection between two Raspberry PI devices. Actually it is easy. Forget about main_blank.c, it is template for new device design. You also don't need OD editor for the start. Its purpose is to prepare documentation for device and to generate CO_OD.h and CO_OD.c files. You can look into makefile in base directory to see, which files are relevant for Linux based device. To connect...
-
Hello, First thing, you are probably using last version on github, master branch. Please note, there is newer and much more up-to-date branch "split-driver", where everithing is much better explained and will soon replace master branch. see: https://github.com/CANopenNode/CANopenNode/tree/split-driver https://github.com/CANopenNode/CANopenNode/issues/108 https://github.com/CANopenNode/CANopenNode/blob/split-driver/doc/deviceSupport.md If you can, please switch to split-driver branch. Driver is very...
-
It's not so easy. You must have a good knowledge of you controller and you programming environment. You can start from here: https://github.com/CANopenNode/CANopenNode/tree/master/stack/drvTemplate
-
CO_PDO_receive() is a callback and it is used from driver (receive interrupt) directly. Check COB-ID in RPDO and transmission type (try with 255). You can also check or debug receive interrup in driver.c and 'CANmodule->rxArray[0..n].ident' variables (Pointer to callback CO_PDO_receive is stored in CANmodule->rxArray[0..n].pFunct.) I don't have good experiences with debugger and interrupts. There was not wery clear behavour.
-
Hi, You have to link PDOs between your devices. You can for example use default TPDOs. For RPDOs you set non-default address. Most simple, in 0x01 device you can just set: /*1400*/ {{0x2L, **0x0188L**, 0xfeL}, ... You can also configure PDOs on running network, that is most usual way for device integrators. Here you can find an interesting article "Good to know: PDO re-mapping procedure": https://can-newsletter.org/engineering/engineering-miscellaneous/160601_can-newsletter-magazine-june-2016
-
Hi, I added all your pull requests. Thank you very much for contribution. Probably is best, if you stay with current version for your device for now. Main change will be Object dictionary and it's interface to the stack. I have to dig into LSS a little. I have access to the standards. I will check, what can be done with driver. Best regards, Janez
-
I'm currently not very familiar with LSS. Is that correct, that LSS is active only in initialization state? If so, then stack can be started after LSS? In near future I will clean the driver interface and separate microcontroller specific code into own git repos. If necessary, we can also change the api. Please note, that IzidorM is currently working on new implementation of OD, there will be also some (hopefuly minor) changes in API. He is quite professional. See https://github.com/IzidorM/CANo...
-
If you will use two CAN ports for the stack (second CAN for some PDOs for example), then you will have to change only files you mention. Most changes probably in canopen.c. I implemented this in one case and it was relatively simple.
-
Hi, I'm still very busy with my projects and still didnt merge your excelent contributions. I will do that soon. It doesn't matter if pull request are per-branch. Cherry-pick is probably possible manually, I will check it, if not too complicated.
-
Hi, In general, CANOpenNode can run on any strog enough device (also may run on 16-bit devices). Each device needs a driver. I can currently support only PICs and Linux. As I know, there was some efforts for NXPs and Windows, but I don't know the state. Plans for near future are, that CANopenNode stack will be separated from drivers. There will be a wiki page, where contributors will put descriptions and links to drivers and examples for their devices. Most recent code will be on https://github....
-
I merged all your pull requests. (Just added one line for initial value NMT->pFunctNMT = NULL; inside CO_NMT_init) Maybe it would be more clear, if you use one branch and only add different commits. But it is OK also. Thank you very much for contributing.
-
I think, it is OK for now. This is currently the only such exception. This problem will be correctly solved with new OD .
-
It is not implemented for dsPIC33. It should be something very similar as for PIC30.
1 >
