AndreasW

as gambid wrote if all the bits are sequential you can check them as dword > 0 ( e.g  [>_U K8M0 K0] ) , in this case be sure to use _U so that K8M0 will be treated as unsigned word, by default its treated as signed word an this case it won't work if the upper bit is set  

Hi never used Device Net, but maybe you will find some information at the DeviceNet Master Slave Module User's Manual https://dl.mitsubishielectric.com/dl/fa/document/manual/plc/sh080143/sh080143o.pdf  

Hello lennyg don't know if there is an easier way, but if you compare the project with itself via (Project | Verify) (just select the Project again as Verify Destination), the Verify List appears. Double click on the line with (Program File Match) to open the window where you can see the Instruction List.  

Hi hewking, don't know kepware, but found this description of the Mitsubihshi Ethernet Driver (for kepware) https://www.kepware.com/getattachment/3daf1ac3-5c76-49ce-bbfe-f0fb1015f6cc/mitsubishi-ethernet-manual.pdf see page 58ff, Appendix PLC Setup for FX3U Series PLC setup, so i would suggest to try it out, but i don't know if its works with the ENET-ADP module. In difference to the ENET module the ENET ADP module (left mounterd to plc) is only providing the ethernet interface (hardware interface) and supporting the Mitshubishi MC-Protocol as described in the manual https://www.allied-automation.com/wp-content/uploads/2015/02/MITSUBISHI_FX3U-ENET-ADP-Ethernet-Users-Manual.pdf, and is primary used to enable commmunictation with other mitsubishi devices (like hmi/robot controller) using the mitsubishi MC-protocol the ADP module/ Ethernet connections can't be programmed from the plc program, but an external device using the mc-protocol can be used to fetch data from the plc so, if  the Kepware driver uses/supports the MC protocol it should work. if the kepware drivers doesn't support mc protocoll, then you will need to use a ENET module. ps: the FX Configurator software is used to configure the ENET module but not the ENET ADP module to your questions: 4.) as far as i know yes only connection at the time 5.) don't know what DSL, DSH area means, as far as i know ther isn't a special adress range used to store string, strings ares stored at hthe reigsisters/variables      that are used in the program using the ASCII character encoding, e.g. string "ABCD" stored to D10 will be stored as      D10 (16bit) : 66 (ASCII b) ,65 (ASCII a) ;      D11 (16bit):  68 (ASCII d), 67 (ASCII c)        

Hi Woszu,  i am not shure if this works, but i would try the following: 1) assign a GOT internal device to the screen switching device for the superimpose window (e.G. GD101)  you can find this setting inside the System Tab "GOT Setting\Environmental Setting\Screen Switchiwing/Window"  2) use a range trigger on your first shown base window to write the screen number of your superimpose window to the screen switching device, if the device has a zero value. (to add a screen trigger right click the base window and select Screen Trigger action...) e.g.: Screen Trigger for the first shown base Window (Screen Trigger Action) TRIGGER SETTING: Trigger Type:   Range Data Type:      Unsigned BIN16 Trigger Device: GD101 (use the Screen Switching Device) Range:          0== GD101 (Expression -> A: ==, B: none) Operation Mode: Satisfied ACTION SETTING Action:         Data Set 16bit Points:        1 Data:           Unsigned BIN16 Device:        GD101 (use the Screen Switching Device) Fixed:          1 (use the screen number of the superimpose window) hope this works  

Hi FX-Zohir, you should have a look at the GX-Works 3 manual, see chapter 15.1 and 15.2 (PROTECTING DATA) https://www.omniray.ch/data/Downloads/20_Automation/210_Steuerungen_SPS/02_Kompaktsteuerungen%20iQ-F-Serie%20(FX5)/02_Handb%C3%BCcher/01_Englisch/20_Software/GX-Works3_OperatingManual_SH-081215-P.pdf if the library is protected by a password, then you have to authenticate the POU you want te edit (see page 458): Operating procedure 1. Select the POU to authenticate the block password, and click the [Authentication] button. 2. Enter the password on the "Password Authentication" screen, and click the [OK] button   if your project is secured by a key, you need to import the key-file inside the security-key-management window.(see chapter 15.2)  

Hi MarkusR, don't know if this will work but maybe you can use the Chanel Shutdown Controls GS539 to disable the corresponding chanel. The Special Registers are described inside the Screen Design Manual inside Chapter 12/GOT special registers

Hi Neverov, you can find this manual at https://dl.mitsubishielectric.com/dl/fa/document/manual/plc/sh080040/sh080040s.pdf for a list of other manuals for L-Series: https://www.mitsubishielectric.com/app/fa/download/search.do?kisyu=/plcl&mode=manual    

you can find several manuals for different PLC Types (Q/L/FX-serias)  at https://www.mitsubishielectric.com/app/fa/download/search.do?mode=manual&kisyu=/plcq for a list of the special special register have a look at the Appendix inside the hardware design manual, eg. for Q-Series CPU https://dl.mitsubishielectric.com/dl/fa/document/manual/plc/sh080483eng/sh080483engax.pdf see Appendix 2 and Appendix 3.    

instead of shifting the bits you can use the swap instruction 1.) MOV HighByteValue  D1                 // move the High-Byte to D1 (this will be stored in the lower 8 Bit of D1) 2.) SWAP D1                                        // swap Hi/Lo of D1 (High-Byte-Value will stored in the upper 8 Bit of D1) 3.) WOR LowByteValue D1                  // OR the value of the Low-Byte of D1     

Hello BL, do you really want to shift the bits of the counter in D0 or is it about reading multiple counter values and store them block by block? If you need to shift the bits of the counter (D0), this can be done with the SHL or SHR instruction, but I can't understand why you should shift bits of a counter. How many bits do you want to shift? If you need to swap high/low byte of the read counter you can use the DSWAP instruction. If you want to store multiple values (each after reading with dhcmov) you don't need a shift instruction. In this case you can the use the BMOV instruction. Alternatively you could use an index register e.g. Z1 and read the values after D0Z1.  

hi david ott,   you wrote: My Test(Wrandom Write) would be as on page 133 and as I thought: new Buffer.from([0x05(subheader), 0xFF(PC No.), 0x0A, 0x00 (monitoring time in 2 parts), 0x04(number of devices?), 0x00 (fixed value),0x16, 0x4E, 0x00, 0x00 (head dev.# in 4 parts), 0x20, 0x52 (device name in 2 part), 0x00, 0x22 (input1 in 2 parts), 0x17, 0x4E, 0x00, 0x00 (head dev.# in 4 parts), 0x20, 0x52 (device name in 2 parts), 0x00, 0x40 (input2 in 2 parts), 0x18, 0x4E, 0x00, 0x00 (head dev.# in 4 parts), 0x20, 0x52 (device name in 2 parts), 0x00, 0x04(input3 in 2 parts),0x1F, 0x4E, 0x00, 0x00 (head dev.# in 4 parts), 0x20, 0x52 (device name in 2 parts), 0x00, 0x01(machineUsed in 2 parts),]);   this should be Ok except for the data values, but should write R19990- R19992 and R19999. i think for the inputvalues you have to switch the order of the High and the Low Byte: e.g. input1 = 22 (dec) = 16 (hex)  --> 0x16, 0x00 (input1 in 2 parts) input2 = 40 (dec) = 28 (hex)  --> 0x28, 0x00 (input2 in 2 parts) input3 = 04 (dec) = 04 (hex) --> 0x04, 0x00 (input3 in 2 parts) ... new Buffer.from([0x05, 0xFF, 0x0A, 0x00, 0x04, 0x00  ,0x16, 0x4E, 0x00, 0x00 , 0x20, 0x52 , 0x16, 0x00 , 0x17, 0x4E, 0x00, 0x00, 0x20, 0x52, 0x28, 0x00,  0x18, 0x4E, 0x00, 0x00 , ....   If your input is a decimal number and if you don't want to convert it to a hex number you also can use the decimal number as input for the buffer, then just leave out the "0x" at the beginning. input1 = 22 (dec) =  22, 0 (input1 in 2 parts) input2 = 40 (dec) = 40, 0 (input2 in 2 parts) input3 = 04 (dec) = 4, 0 (input3 in 2 parts) new Buffer.from([0x05, 0xFF, 0x0A, 0x00, 0x04, 0x00  ,0x16, 0x4E, 0x00, 0x00 , 0x20, 0x52 , 22, 0 , 0x17, 0x4E, 0x00, 0x00, 0x20, 0x52, 40, 0,  0x18, 0x4E, 0x00, 0x00 , ....     regarding the value 255: that was only a hint, which is about the High Byte. If the value is in the range 0-255 (dec) the high byte is 0 and the low byte is equal to the value, therefore it can be written in the buffer as [VALUE, 0] as above. For values > 255 (dez) it is easier to represent the number hexadecimal, because you can directly see the high/low byte. e.g. 16589 (dec) = 40CD(hex) => Low-Byte= 0xCD, High-Byte= 0x40        

Hello David Ott, if there are only 10 registers you can of course simply write zero to the other registers (R19993-R19998) if these registers are not used in the PLC. If you do this, you should mark the registers as used/written in the device comments of the PLC, so that they are not accidentally used later. Alternatively you can use the function Test(Wrandom Write) to write only the selected registers, see page 133 in the SLMP manual https://dl.mitsubishielectric.com/dl/fa/document/manual/plcf/jy997d56001/jy997d56001j.pdf In both cases the values written are 16 Bit, that mean you have to write two bytes for each value (high byte and low byte, in the order LOW, HIGH). i.e. if the value to write is <= 255 (decimal) => High-Byte= 0x00, "var writeBuffer = new Buffer.from([0x03, 0xFF, 0x0A, 0x00, 0x16, 0x4E, 0x00, 0x00, 0x20, 0x52, 0x03, 0x00, input1format, 0x00, input2format, 0x,00, input3format, 0x00]);" if the value is > 255 the corresponding high byte must be written e.g. 16.589 (dec) = 40CD(hex) => 0xCD, 0x40  

hi david ott, if you receive 192, 86 (81h, 5Bh) this is the error code, because the send request is wrong, i forgot that the send buffer also need the data in high order, to receive R20000 and following register use the following send buffer: let sndBuff= new Buffer([0x01, 0xFF, 0x0A,0x00, 0x20,0x4E,0x00,0x00,  0x20,0x52,   0x09,0x00]); 0x01 ... command: batch read word units 0xFF ... pc-no 0x0A, 0x00 .... timeout (000Ah) 0x20, 0x4E, 0x00, 0x00 .... start adress (00004E20h .... = 20000) 0x20, 0x52 .... register type (5220h = R-Register) 0x09 .... number of register to read 0x00 ... endcode inside the receive function you have to convert/combine the received bytes to an 16 bit value (signed/unsigned, depending on the data type used in the plc) Therefore you can use an Int16 Array or an UInt16 Array.   client.on('data', function(data) {     let buff= Buffer.from(data);     console.log('Received: ');     console.log(buff);     const int16array = new Int16Array(         buff.buffer,         buff.byteOffset,         buff.length / Int16Array.BYTES_PER_ELEMENT);     console.log(int16array);     const uint16array = new Uint16Array(         buff.buffer,         buff.byteOffset,         buff.length / Uint16Array.BYTES_PER_ELEMENT);     console.log(uint16array);     let value1= (buff[3] << 8 ) | buff[2];     let value2= (buff[5] << 8 ) | buff[4];     console.log('value1=' + value1);     console.log('value2=' + value2);     client.end(); });  

hi David Ott, the response 91,16 (5Bh, 10h) is an error code, i think this is because the request you send to plc is wrong; -> could you show me the Request you send to PLC (for binary)? for your request string "01FF000A522000004E200900" (in ASCII) this should be something like: let sndBuff= new Buffer([1,255,0,10,0,0,78,32,82,32,9,0]); client.write(sndBuffer, ()=>{                 timeout= setTimeout(()=> {                     console.debug('error: timeout occured, no data received for last ReadRequest');                     EndConnection();                 }, 1500);   be aware that the position of the device code and the head device are switched in the binary version, see page 124 in the SLMP manual https://dl.mitsubishielectric.com/dl/fa/document/manual/plcf/jy997d56001/jy997d56001j.pdf    

hi david ott, i think the problem is that you send the wrong request. If you set the data code to BINARY, you have to change the nodejs and the Request you send to the plc. The request has to be send as Bytre-Array and not as a string. Also the response data from the plc can't be interpreted as string all you recieve are bytes. The response is no longer the string "8100" (4 bytes) but only 2 bytes with the value 81h and 00h, and if you use console.log to visualize/show these two bytes are interpreted as utf-8 characters and console.log will show the corresponding symbols to see the received bytes you can use an Buffer object, so in your nodejs program change the client.on function to show the received bytes.   ///// nodejs (OLD) works for ASCII //////////////////////////////////// client.on('data', function(data) {     console.log('Received: ' + data);    <--- received data are ASCII coded so console.log can show them as STRING     client.end(); }); ///// nodejs (NEW) //////////////////////////////////// client.on('data', function(data) {     let buff= Buffer.from(data);     console.log(buff);                            <--- Buffer object hold the received Bytes, console.log show the received Bytes     client.end(); });        

hi david ott, i still don't understand what exactly is the problem? or why the SLMP communication should be changed to BINARY? Are you now concerned about the connection PLC to PC (nodejs) or the connection between robot/HMI to PLC? You wrote:  "With such a setup in ascii format, the robot and HMI cannot communicate with PLC, but only PC can. So system needs to be changed to binary format." I don't understand how the change from ASCII to BINARY should change anything here, or why this should be necessary. If no other devices than the PC can connect to the PLC, you should check if you have configured enough connections in the network settings. If necessary you have to add more connections here. (Parameter|FXCPU|Module Parameter|Ethernet Port|External Device Configuration)   If you still want to use the BINARY variant (although I doubt this is necessary) you have to modify the nodejs program accordingly of course.    

hi David Ott, I don't quite understand what influence a robot or an HMI should have on the communication between PLC and PC?  Or is it about to handle a communication between robot and PLC also over the MC protocol ? Or is it about the fact that only the PC but neither the HMI nor the robot can establish a connection to the PLC? If it is the latter, you should check if you have enough free Ethernet/SLMP connections in the network configuration of the PLC. (Parameter|FXCPU|Module Parameter|Ethernet Port|External Device Configuration),if no other connections are configured here, only one client can communicate with the PLC at a time.) If you want to establish a communication between PLC and robot via the MC protocol, this must be programmed on the robot side, if this is basically supported by the robot, it should then also be the same whether the MC protocol is used as ASCII or BINARY variant and also in this case the ASCII variant should be easier to program, at least for the robots that I know (Mitsubishi, Epson, ABB).   The difference between the ASCII and BINARY variant iof the MC-protocoll is basically only in the number of bytes to be sent and the values. See the SLMP manual (chapter 3.2 1E frame, and chapter 5.2 device access). https://dl.mitsubishielectric.com/dl/fa/document/manual/plcf/jy997d56001/jy997d56001j.pdf Maybe again to explain why the ASCII variant is a bit easier to program. As an example the request string for reading D2050 should serve: in the ASCII variant the request string is structured as follows: "01 FF 000A 4420 00000802 01 00" "01 FF 000A 4420 00000802 01 00"    --> 01 (cmd)... batch read 1 word unit [2 byte, 30h, 31h] "01" --> FF (pcnr, fixed) [2 bytes, 46h, 46h] "FF" --> 000A (timeout 10x250ms= 2.5sec) [4 byte, 30h, 30h, 41h] "000A" --> 4420 (devcode for d-register) [4 byte, 34h, 34h, 32h, 30h] --> 00000802 (start address in hex h802= decimal 2050) [8 Byte] --> 01 (counter in hex= h01= decimal 01 = 1 register) [2 byte] --> 00 (end, fixed) [2 byte] Strictly speaking, we do not have to send the STRING, but the byte stream consisting of 24 bytes (hex: 30,31,46,46,30,30,41,34,34,32,30, ....) This Byte stream corresponds exactly to the ASCII character set, which is why we can simply pass this "byte array" as an ASCII string to the functions such as client.write(...) without having to build the byte array manually for this purpose. If, for example, the above request is not to be sent as ASCII but as BINARY, the structure changes (see Chapter 5.2, page 124). CMD --> 1 byte 01h, instead of string "01" = [30h, 31h] PCNR --> 1 byte: FFh, instead of string "FF" = [46h,46h] TIMEOUT --> 2 byte: 00h, 0Ah, instead of string "000A" = [30h,30h,30h,41h] START ADDRESS --> 4 bytes: 00h, 00h, 08h , 02h instead of string "00000802 " = [30h,30h,30h,30h,30h,38h,30h,32h] DEVICE-CODE -> 2 Byte: 44h, 20h, instead of string "4420" = [34h,34h,32h,30h] COUNTER -> 1 byte: 01h, instead of string "01" = [30h, 31h] END -> 1 byte: 00h, instead of string "00" = [30h, 30h] the whole request consists then only of 12 bytes instead of 24 bytes, these 12 bytes must be written within the program first manually into a byte array and can be sent then likewise by client.write. So in nodejs instead of client.write("01FF000A4420000008020100") would be would rather result in something like this testBuff = new Buffer([1, 255, 0, 10, 0,0,8,2, 68, 32, 1, 0]); client.write(testBuff); the response data would then also be processed as a byte array. Since only the byte data arrives here and client.write only returns the raw data, the byte order (endianess) must be taken into account.available String functions can't be used to split the received data, and so on.... So in total this would be much more complex and I have never seen a system where the communication can't be solved with the ASCII-Varainte. The BINARY variant has only the advantage that less data must be transferred, but this should normally not be a problem.    

Hi, if you push the Jump_Step ("Finish Step") this will set 'Step_1_Done' (Network1), then in Network2 both steps are executed in the same process cycle, so it jumps directly to network3/step3. To Prevent this you should check that 'Step_1_Done' is not set ( in Network3 use 'Step_2_Done', and so on)      

Hi, don't know if this is what you need, but for the GOT have a look at the GOT2000 Connection Manual, chapter 2.3.2, page 2-14 (Microcomputer connection, serial, RS422 cable) shows a pin assignment https://si3a.mitsubishielectric.com/fa/sl/dl/11079/SH(NA)-081200ENG-W.pdf for the FX3U https://eu3a.mitsubishielectric.com/fa/en/dl/1191/137315.pdf, page 2-44, tab 2-19 and https://www.allied-automation.com/wp-content/uploads/2015/02/MITSUBISHI_FX3GFX3UFX3UC-Users-Manual-%E2%80%93-Data-Communications-Networking.pdf chapter H (Programming communication)  H4.2 (Cable connection diagrams) (page 682)  

you have to be a bit more specific, what do you want to achieve? as I understand it, you want an axis to track depending on a value (should a position or speed be tracked?) what is the response time, how do you control the axis (A/B phase via output or via SSCNET and positioning module?). In the simplest case monitor the corresponding value in the PLC for change and set a corresponding move command, if the normal cycle time is too slow use an interrupt for monitoring/control.

Hi Transistor, good that it works again. The Module lablels are added to the Structured Data types after inserting an module in the Module Configuration (if using module labels is enabled). after changing the module configuration or if using another gx3/module library version it can happens that the module labels won't match, in this case you should delete the labels and recreate them. this also can occure when you accidentally delete an type. in this case you can't compile/rebuild and the labels stay 'red'. in this case delete the module labels an recreate them (seen next image)

the first message indicates that there is an mismatch in the structured data types of the automatic module labels (did you change the module configuration or gx3 version?). Maybe it helps if you recreate the module labels. you should check the plc error code using [Diagnositc]=> [Module Diagnostic (CPU Diagnostic)], maybe this helps  

Hello Transistor, check if there is enough free memory in the PLC, the free memory is shown at the bottom of the transfer dialog. If everything is transferred, also the device and label comments are transferred, then the free memory may be too small. In this case it helps not to save the comments in the PLC. It may also help to load the parameters and the program separately into the PLC, i.e. first write the parameters (CPU+ module parameters), then reset the PLC and then write the program (label + FBFiles). If not already done, you should also read out all actual values from the PLC (device memory), so that these can be restored if necessary, this can save a lot of time and work. good luck  

as glavanov wrote it depends on the type of servo and inverter. At the moment I know only MRJ3 and MRJ4 inverters and the software MR-Configurator2, therefore the following information refers only to the two inverter types, but should work in principle also with other inverter types. When using auto-tuning via the inverter, the number of output pulses as well as the type (High/Standard/Low) can be set. I would position the axis approximately in the center of the travel range before auto-tuning is started. At the first run I would choose the number of output pulses so small that less than one motor revolution takes place (Attention: if due to the gear factor one motor revolution is already too much, then less). The distance travelled by the axis during auto-tuning is usually much greater than the real distance travelled during the corresponding revolution, this depends largely on the setting of the permissible 'overshoot amount'. Afterwards, the number of output impulses can be increased so that the largest possible driving range of the axis is covered. The auto-tuning usually works relavtivly well, if you have vertical axles and/or off-center loads one must mostly still adjust the resonance filter somewhat. Good luck