I am developing a program to connect my PC to Omron CJ2M PLC to send read / write commands.
As per my understanding, Omron PLCs can be communicated over 3 methods:
1) Hostlink,
2) FINS, (TCP or UDP) and
3) EIP.
My requirement here is to connect CJ2M through EIP, and send Read/Write commands over EIP(CIP) protocol.
Initally EIP communication needs to send 2 requests:
1) List Services and 2) Register Sessions
Register Sessions returns a handle which should be used in further communication over EIP.
I am successfully able to send List Services, Register Session and Forward Open (RR Data) and these are successfully replied by the Omron PLC. There is no problem in these 3 requests/responses.
Now I want to know which command/service need to be used to read the memory area of Omron (say DR 20 memory address).
I am sending service code 0x4d over RR Data, but it says "Vendor Specific Error" and then connection gets terminated.
I need protocol specification for Omron EIP or wireshark logs or some sniffed packets where a request / response is captured over EIP communication from PC to Omron PLC (no fins, no hostlink).
We can send requests to Omron EIP using "Send Unit Data" with service code 0x4d.
This service (0x4d) is used to send write request as per EIP documentation, but we can insert the Omron specific commands (FINS) to read the memory areas in command specific data.
0000 00 00 00 00 00 80 0e 00 01 00 80 00 02 00 00 00
0010 00 00 00 12 01 01 82 00 00 00 00 01
Related
I am trying to get CAN communication running via an external SBC (TLE9263) board.
Microcontroller: S32K312
Ext. SBC board: TLE9263_EVB_2
Without SBC, i.e., using a standard external CAN transceiver TJA1057GT, CAN communication is running.
With SBC, some messages are received once, but then the SBC transceiver goes down, and CANIF_E_FATAL Det error occurs (Call Stack).
I configured the SBC registers as follows: SBC registers configuration
The following values are observed on the SPI-MOSI signal:
41 00 - SUP_STAT_1
82 00 - HW_CTRL
81 1F - M_S_CTRL
84 07 - BUS_CTRL_1
85 00 - BUS_CTRL_2
83 82 - WD_CTRL
The above observed values are expected in my opinion. What could be the cause of communication not working?
Additionally (not sure if this is relevant), the Fail Output LEDs on the TLE9263 board, FO1 and FO3 are ON as soon as the board is powered, and FO2 is blinking, and this status of the LEDs remains the same when the software is run.
Here is my code:
#pragma comment (linker, "/INCLUDE:_tls_used")
#pragma comment (linker, "/INCLUDE:p_tls_callback1")
#pragma const_seg(push)
#pragma const_seg(".CRT$XLAAA")
EXTERN_C const PIMAGE_TLS_CALLBACK p_tls_callback1 = tls_start_protect;
#pragma const_seg(pop)
and following piece of code is directly called by tls_start_protect.
char buf[10];
sprintf_s(buf, 10, "hello\n");
and it crashes.
0:000> k
# Child-SP RetAddr Call Site
00 0000007c`e676eb58 00007ff6`e3b04829 AGTtest!__crtFlsGetValue+0x10 [f:\dd\vctools\crt\crtw32\misc\winapisupp.c # 422]
01 0000007c`e676eb60 00007ff6`e3b047f3 AGTtest!_getptd_noexit+0x1d [f:\dd\vctools\crt\crtw32\startup\tidtable.c # 277]
02 0000007c`e676eb90 00007ff6`e3b03737 AGTtest!_getptd+0xb [f:\dd\vctools\crt\crtw32\startup\tidtable.c # 337]
03 0000007c`e676ebc0 00007ff6`e3b06030 AGTtest!_LocaleUpdate::_LocaleUpdate+0x1b [f:\dd\vctools\crt\crtw32\h\setlocal.h # 248]
04 0000007c`e676ebf0 00007ff6`e3b02816 AGTtest!_output_s_l+0x6c [f:\dd\vctools\crt\crtw32\stdio\output.c # 1028]
05 0000007c`e676ef10 00007ff6`e3b028a8 AGTtest!_vsnprintf_helper+0x92 [f:\dd\vctools\crt\crtw32\stdio\vsprintf.c # 140]
06 0000007c`e676ef80 00007ff6`e3b025a3 AGTtest!_vsprintf_s_l+0x3c [f:\dd\vctools\crt\crtw32\stdio\vsprintf.c # 237]
07 0000007c`e676efc0 00007ff6`e3b0112f AGTtest!sprintf_s+0x1f [f:\dd\vctools\crt\crtw32\stdio\sprintf.c # 216]
08 0000007c`e676f000 00007ffb`bd6a52c8 AGTtest!tls_start_protect+0x1f [d:\repos\antidebug\agt\tls_callback.c # 83]
09 0000007c`e676f040 00007ffb`bd6a1577 ntdll!LdrpCallInitRoutine+0x4c
0a 0000007c`e676f0a0 00007ffb`bd7201cd ntdll!LdrpCallTlsInitializers+0x93
0b 0000007c`e676f120 00007ffb`bd75166d ntdll!LdrpInitializeProcess+0x1c99
0c 0000007c`e676f510 00007ffb`bd706d5e ntdll!_LdrpInitialize+0x4a8b9
0d 0000007c`e676f590 00000000`00000000 ntdll!LdrInitializeThunk+0xe
Similarly family of _vscprintf(format, args) also crash in __crtFlsGetValue.
I wonder it's too early to call family of printfs, before which, initialization haven't been done. What I know is that TLS callback(Only DLL_PROCESS_ATTACH) is executed after 'ntdll!Ldr*' load all dependent modules and before 'EOP'.
Question:
Any detail about the initialization of _vscprintf, is it done by "CRT" in some CPP constructors' code???
Any other restriction of TLS callback???
If I do need to call _vscprintf in TLS Callback, how? (somehow, I just wanna print before main)
you use static linked CRT - this is visible from your stack trace. static linked CRT in exe initialized after exe entry point is called. but tls callback on DLL_PROCESS_ATACH called before exe entry point. in this case your static CRT yet not initialized and any call to this CRT code can crash. solution - use dynamic linked CRT in separate DLL - in this case it already will be initialized before TLS callback
when I send an API ND command to a remote endpoint I get ???
When I send an API ND command from a VB program using the following packet;
7E 00 05 08 01 4E 44 00 64
I get;
7E 05 3F 14 E4 41 3F
Its a response -- but not as I know it. Neither the checksum "3F" or command length "05" are comprehensible to me. On the other hand if I wait for more bytes by setting "Serialport1.ReceivedBytesThreshold" (threshold: 10 bytes in buffer > event is fired) to 10 the "SerialPort1.ReadExisting()" statement times out. Any suggestions for decoding? Both coordinator and endpoint are XBEE PRO S2Bs.
I don't think it makes sense to send ATND as a remote AT command, and it will probably be ignored on the remote node, or trigger node discovery at that node with the responses staying local.
It looks like your response is possibly dropping null bytes (0x00), like the MSB of length, and one more in the packet itself. I'm not familiar with a frame type of 0x3F though -- is it documented for that XBee module you're using?
After a node discovery, you should see multiple AT Response frames (type 0x88?) come back over some time (based on ATNT, I believe), until you get one with a short payload (indicating discovery is complete).
I'm trying to connect two xbee's pro s2 and make them communicate with each other in API Mode (further, I will use more end and router devices). Basically, I have a xbee coordinator plugged on my PC through digi adapter and I have other xbee connected to a PIC18f25. Right now I'm working on send and receive data from one to another and vice versa.
When I connect both on the usb adapter, the communication works just fine (I can send and receive data from/to both devices). However, when I try to work with the previous configuration, I find it impossible to get the data, which is sent from the coordinator, from the end device with the PIC. Here goes the data that I'm trying to send:
From Coord 2 EndD - 7E 00 13 10 01 00 13 A2 00 40 8D 5A 8B FF FE 00 00 48 65 6C 6C 6F 96
From EndD 2 Coord - 7E 00 13 10 01 00 00 00 00 00 00 00 00 FF FE 00 00 48 65 6C 6C 6F FD
I think it's usable to say that when I try to send the data from the PIC, through end device, to coordinator, it works.
I wonder if the problem relies on my code, which can be found below:
#include <18F25K20.h>
#device adc =10
#device ICD=TRUE
#FUSES noWDT // Watch Dog Timer
#fuses LP //low power crystal
#FUSES XT //Crystal osc <= 4mhz
#fuses BROWNOUT_SW //Brownout enabled during operation, disabled during SLEEP
#FUSES NOPROTECT //Code not protected from reading
#FUSES BROWNOUT //brownout reset
#FUSES BORV27 //Brownout reset at 2.7V
#FUSES NOPUT //Power Up Timer
#FUSES NOCPD //No EE protection
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES noDEBUG //No Debug mode for ICD
#FUSES noLVP //Low Voltage Programming on B3(PIC16) or B5(PIC18)
#FUSES NOWRT //Program memory not write protected
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES noIESO //Internal External Switch Over mode enabled
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES NOPBADEN //PORTB pins are configured as analog input channels on RESET
#FUSES NOWRTC //configuration not registers write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOEBTRB //Boot block not protected from table reads
#FUSES NOCPB //No Boot Block code protection
#FUSES LPT1OSC //Timer1 configured for low-power operation
#FUSES MCLR //Master Clear pin enabled
#FUSES XINST //Extended set extension and Indexed Addressing mode enabled*/
#use delay(clock = 4000000) /* Clock definition */
#use rs232(BAUD = 9600, XMIT = PIN_C6, RCV = PIN_C7) /* ZigBee and PIC Communication */
int16 var;
byte var2=0x00;
long timeout;
void main() {
output_low(PIN_C5); // Turning on Xbee
delay_ms(10);
while(1) {
delay_ms(100);
output_high(PIN_C0); // TESTE
delay_ms(100);
output_low(PIN_C0);
timeout=0;
while(!kbhit()&&(++timeout<5000)) delay_us(5);
if(kbhit()){
output_high(PIN_C0);
delay_ms(10);
output_low(PIN_C0);
delay_ms(10);
output_high(PIN_C0);
delay_ms(10);
output_low(PIN_C0);
delay_ms(10);
output_high(PIN_C0);
delay_ms(10);
output_low(PIN_C0);
var2 = getc();
delay_ms(1000);
}
/* Data which is succesfully sent to coordinator
putc(0x7E);
putc(0x00);
putc(0x13);
putc(0x10);
putc(0x01);
putc(0x00);
putc(0x00);
putc(0x00);
putc(0x00);
putc(0x00);
putc(0x00);
putc(0x00);
putc(0x00);
putc(0xFF);
putc(0xFE);
putc(0x00);
putc(0x00);
putc(0x48);
putc(0x65);
putc(0x6C);
putc(0x6C);
putc(0x6F);
putc(0xFD);*/
}
}
The program is supposed to blink a LED (PIN_C0) with 100 ms, and blink it faster if any data enter in the PIC. However it doesn't work as I planned and I have no clue why.
Any help will be appreciated.
Thank you all in advance,
Regards.
You know that a lot of pieces are working at this point. If the PIC is sending frames to the XBee module that the coordinator receives, then:
You have the correct baud rate.
You at least have the PIC Tx hooked correctly to the XBee Rx.
The XBee module has power and is running.
The XBee module is joined to the coordinator's network.
The RESET line of the XBee module is asserted correctly.
Is it possible that you have hardware handshaking enabled (ATD6=1) on the XBee module, so it's failing to send to the PIC due to it not asserting RTS?
Can you connect a standard serial cable to the PIC (instead of the XBee), and confirm that data sent in from a terminal program triggers your flashing, and that the terminal program sees the sent frame?
Can you use an XBee interface that flashes LEDs on Tx and Rx so you can visually see if data is coming through?
In the SSL client, I am receiving a serverHello message with tampered message length like below.
"16 03 00 00 35 02 00 08 00... "
Here, "00 08 00" is message length which is coming as 2048 bytes. But in the next record, it sends "serverCertificate & serverHelloDone" messages.
So, in the client side, it waits to read 2048 bytes. but messages "serverHello, serverCertificate, serverHelloDone" are not having 2048 bytes combinedly. So, still client waits to read pending message (socket is blocking socket). So, it just waits in recv and never comes out.
I would like to know how applications should handle this situation. Is there any way in SSL protocol, we can identify this. If not possible, how applications should handle this situation to come out ?
Thank you !
Regards
Satish.