I was reading in the CANopen device number EL6751-0010, of course, using the SDO reading command, which I did as follows:
603 | 40 7A 60 00 00 00 00 00
and gave me the following error:
583 | 80 7A 60 00 00 00 02 06
I realized that this object does not exist.
What should I do to find all the objects of an Object Dictionary?
Finally, I can write and read code in the right place.
Related
I'm struggling with an old radiation sensor and his communication protocol.
The sensor is event driven, the master starts the communication with a data transmission or a data request.
Each data telegram uses a CRC16 to check only the variable data block and a CRC8 to check all the telegram.
My main problem is the crc16, According to the datasheet the poly used to check the data block is: CRC16 = X^14 + X^12 + X^5 + 1 --> 0x5021 ??
I captured some data with a valid CRC16 and tried to replicate the expected value in order to send my own data transmission, but I can't get the same value.
I'm using the sunshine CRC calculator trying any possible combination with that poly.
I also try CRC Reveng but no results.
Here are a few data with the correct CRC16:.
Data | CRC16 (MSB LSB)
14 00 00 0A | 1B 84
15 00 00 0C | 15 88
16 00 00 18 | 08 1D
00 00 00 00 | 00 00
00 00 00 01 | 19 D8
00 00 00 02 | 33 B0
01 00 00 00 | 5A DC
08 00 00 00 | c6 c2
10 00 00 00 | 85 95
80 00 00 00 | 0C EC
ff ff ff ff | f3 99
If I send an invalid CRC16 in the telegram, the sensor send a negative acknowledge with the expected value, so I can try any data in order to test or get more examples if needed.
if useful, the sensor uses a 8bit 8051 microprocessor, and this is an example of a valid CRC8 checked with sunshine CRC:
CRC8 = X^8 + X^6 + X^3 + 1 --> 0x49
Input reflected Result reflected
control byte | Data |CRC16 | CRC8
01 0E 01 00 24 2A 06 ff ff ff ff f3 99 |-> 0F
Any help is appreciated !
Looks like a typo on the polynomial. An n-bit CRC polynomial always starts with xn. Like your correct 8-bit polynomial. The 16-bit polynomial should read X16 + X12 + X5 + 1, which in fact is a very common 16-bit CRC polynomial.
To preserve the note in the comment, the four data bytes in the examples are swapped in each pair of bytes, which needs to be undone to get the correct CRC. (The control bytes in the CRC8 example are not swapped.)
So 14 00 00 0a becomes 00 14 0a 00, for which the above-described CRC gives the expected 0x1b84.
I would guess that the CRC is stored in the stream also swapped, so the message as bytes would be 00 14 0a 00 84 1b. That results in a sequence whose total CRC is 0.
I am trying to display the video my (PAUL) drone is sending to my over a UDP connection.
Frames look like (hexdump):
00 00 01 a1 00 1d 00 03
90 1a 00 00 a0 8a dc 0c
00 00 00 00 03 00 00 00
d0 02 40 02 00 04 00 00
90 1a 00 00 19 00 ......
Frames always start (trough my observation) with:
00 00 01 a
Are these NAL units?
I am want to display this in VLC player but don't know how to stream it to the VLC media player.
It looks a lot like a valid h.264 bitstream, but its not. 00 00 01 does look like a start code, But after a start code the first bit MUST be 0. a in binary is 1010 hence not valid.
I want to configure a Kollmorgen drive to rotate a motor with constant velocity via CANopen. I am using SDO mode for it.
My drive device id is 0614. So far I have configured it as:
Id=0614, Data= 2F 04 22 00 50 00 00 00 'Set run current to 80%
Id=0614, Data= 23 84 60 00 40 42 0F 00 'Set deceleration to 1M steps/sec^2
Id=0614, Data= 23 83 60 00 40 42 0F 00 'Set acceleration to 1M steps/sec^2
Enable motor power
Id=0614, Data= 2B 40 60 00 06 00 00 00 'Ready to Switch on
Id=0614, Data= 2B 40 60 00 07 00 00 00 'Switched on
Id=0614, Data= 2B 40 60 00 0F 00 00 00 'Operation Enable
Set to Profile Velocity Mode
Id=0614, Data= 2F 60 60 00 03 00 00 00 'Set to Profile Velocity Mode
Target Velocity -
Id=0614, Data= 23 FF 60 00 50 C3 00 00 'Target Velocity 50K
The problem I am facing is that whenever I am trying to enable the drive it gets disabled automatically. When I try to read StatusWord is gives 0270. Which means the device is disabled. It doesn't give any warning or fault.
the device Id in canopen protocol could not be bigger than 127. the COB ID of SDO download is 0x600+nodeID and the COB ID of SDO upload is 0x580+nodeID
I think the Id of your device is 0x14.also sdo DOWNLOAD message just include 4 bytes of data and the second third and fourth data are including the address OD 'S index and sub index that you want write to it and the first byte is specifier that is shown below
Please,
I am trying to write a simple Binary Block to mifare 1k tag with a ACR122U reader.
I am trying write to block 01, 5 bytes, text:'teste' and read it back.
But I always get an error 6300 when update this block.
Any thoughts?
I am using windows 8.1/delphi xe8.
My log is:
SCardEstablishContext succeeded.
Card State changed in ACS ACR122U PICC Interface 0 to available
New reader found: ACS ACR122U PICC Interface 0
Card inserted in ACS ACR122U PICC Interface 0
ATR = 3B 8F 80 01 80 4F 0C A0 00 00 03 06 03 00 01 00 00 00 00 6A
SCardConnect (shared) succeeded.
Active Protocol: T=1
ISO 14443 A, Part3 Card Type: Mifare Standard 1K is detected
Sending APDU to card: FF 82 00 01 06 FF FF FF FF FF FF
SCardTransmit succeeded.
Card response status word: 9000 (OK)
Sending APDU to card: FF 86 00 00 05 01 00 01 60 01
SCardTransmit succeeded.
Card response status word: 9000 (OK)
Sending APDU to card: FF 86 00 00 05 01 00 01 60 01
SCardTransmit succeeded.
Card response status word: 9000 (OK)
Sending APDU to card: FF D6 00 01 05 74 65 73 74 65
SCardTransmit succeeded.
Card response status word: 6300 (State of non-volatile memory changed.)
This is easily resolved by reading the documentation.
You're writing to a block and you have to provide a complete block of information. The only option for Lc is x04 or x10 - four bytes or sixteen bytes. For the Mifare 1K, it's prettly clear that you need to supply 16 bytes. You have only 5 bytes of data, so pad the rest with zeros.
| CMD | block1 | 16 bytes | data ...
FF D6 00 01 10 74 65 73 74 65 00 00 00 00 00 00 00 00 00 00 00
Why does bios read at partition's boot record at 0000:7c00 ? What is special about that address ? what ':' doing in referencing an address ?
The simple answer is that 7C00h is 1k (512 bytes for the boot sector plus an additional 512 bytes for possible boot sector use) from the bottom of the original 32k installed memory.
The happy answer is that org 7C00h has become synonymous with boot sector - boot loader programming.
The ":" is a holdover from segmented memory days, when PCs ran in real mode and could only do 64K at a time. The number to the left of the ":" is your segment, the number to the right is your address.
The windows debug command accepts this notation if you want to poke around in memory yourself:
C:\Users\Seth> debug
-d0000:7c00
0000:7C00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0000:7C10 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0000:7C20 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0000:7C30 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0000:7C40 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0000:7C50 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0000:7C60 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0000:7C70 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
With regard to this particular address, it's just an address that was picked to load the MBR, See: https://web.archive.org/web/20140701052540/http://www.ata-atapi.com/hiwmbr.html
"If an MBR is found it is read into memory at location 0000:7c00 and INT 19 jumps to memory location 0000:7c00"
In the original IBM PC it was thought inconceivable to have more than 32K RAM. In segmented addressing terms this is 0000:8000 where 8000 hex is 32768 decimal. The fashion of the time was for the BIOS POST conclude by loading the Boot Sector of the floppy in A: or the Master Boot Record of the hard drive in C: at the location 512 bytes below the top of memory which means subtract 0200 hex from 8000 hex to get 7C00. So the boot sequence loaded the first valid 512 byte first sector into, and then set the Instruction Pointer to 0000:7C00 to execute it. I used to write the code for these first sectors to load the operating system.
Read this article:
http://en.wikibooks.org/wiki/X86_Assembly/Bootloaders
From the above URL, BIOS (which is effectively PC hardware) will make the jump to memory at 0000:7c00 to continue execution in 16-bit mode.
And to quote from above:
A bootloader runs under certain conditions that the programmer must appreciate in order to make a successful bootloader. The following
pertains to bootloaders initiated by the PC BIOS:
The first sector of
a drive contains its boot loader.
One sector is 512 bytes — the last
two bytes of which must be 0xAA55 (i.e. 0x55 followed by 0xAA), or
else the BIOS will treat the drive as unbootable.
If everything is in
order, said first sector will be placed at RAM address 0000:7C00, and
the BIOS's role is over as it transfers control to 0000:7C00. (I.e. it
JMPs to that address)
So from bootup, if u want the CPU to start executing your code, it has to be located in memory at 0000:7c00. And this part of the code is loaded from the first sector the harddisk - also done by hardware. And it is only the first sector which is loaded, the remaining of other parts of the code then have to be loaded by this initial "bootloader".
More information on harddisk's first sector and the 7c00 design:
http://www.ata-atapi.com/hiwdos.html
http://www.ata-atapi.com/hiwmbr.html
Please don't confuse with the starting up mode of the CPU - the first instruction it will fetch and execute is at physical address 0xfffffff0 (see page 9-5):
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf
and at this stage it is executing non-volatile (meaning you cannot reprogram it easily, and thus not part of bootloader's responsibility) BIOS code.