Parky

Here. this assumes your physical stop button is N/C type so it can be started/Stopped from the I/O or from the HMI

Normally, you would not use the physical I/O to control the motor but use internal bits to control the motor output Like the attached, Cannot remember the memory map (internal bits/words) but the only physical I/O will be the output to drive the motor (assuming this is a simple direct on-line motor wired not communicating to a VFD. Use internal bits for buttons on HMI but you could use the physical output in the PLC & display its status using that bit. Your post is a liitle lacking information but below is a simple start stop logic using HMI buttons linked to internal bits as energise when pressed

The E300 is only 422/232 so probably will not work as 485 requires enabling/disabling the send/recieve lines so you would probably need some 485/422 interface plus the E series was EOL some years ago better to go with the GOT.

In Sysmac Studio, the AT variable attribute is used to explicitly assign a variable to a specific physical memory address or to link an internal variable to a system-defined variable (like an axis or I/O variable). Direct Memory Access: For older communication protocols like FINS or specific hardware interfaces that require physical memory addressing, the AT keyword allows you to map a symbolic variable (For example My_Var) to a physical memory location (e.g., %Mxx). This makes it compatible to many things like an HMI that can only communicate using physical addresses. The New IEC 61131 tries to get away from physical addressing in favour of symbolic in other words rather than have the fixed like I 0.0 Q 1.3 M200 & D23 you just use a symbolic name However, Sysmac & others actually assign physical addresses to the existing fixed memory areas when compiled but HMI's & the like do not know where the location is so that is the reason, In RSL5000, they have ditched the physical fixed addressing & the compiler & runtime system uses purely symbolic addressing. there must be a physical allocation table somewhere that knows the allocated physical address, Mitsubishi do the same as Omron so still use physical addresses at compile time.

It would certainly help to know more information, for example it is not clear if those so called locations are fixed & why copy bits from one array to another but ignore certain ones does not really make sense, once a certain location deemed to be ignored as far as the index lookup why copy the next location in essence reducing the amount of data in the array. What is the purpose of just ones/zeros & removing a certain locations I think for others to give valid ideas the OP needs to be a bit more forthcoming & at least reply to the above posts.

I have not used AB for some years but probably best done in ST. Depending on the processor 1600 elements is a fair bit of processing, however, I would use ST in a loop Although this is done on another platform & assumed this is effectively copying a number of bits to another array but that array may only effectively shift the data up due to if the index is equal to one of those numbers then the array your copying from is say 1000, the array you are copying to will end at 1000 minus the numbers of the case statements for example if you have 1000 in an array 1 & there are 100 array element positions that will not be copied for a 1 to 1 basis then we increment the index to copy the array +1, it is assumed then that the number of bits copied from array 1 to array 2 will be 1000 minus 100 i.e. 900.

I agree with Chris, did this on about 5 production lines then used Kepware to log the information to an SQL DB, used Excel with VBA to create a template sheets that anybody logged on to the corporate network could access the data, we also had a small system that gave live data that I wrote from scratch in Delphi & used OPC via the kepware for live information.

The PCD file is a packed database I believe (a sort of zip), it needs to be extracted by GXIEC saved then opened & converted in GXWorks2, it does not always work for example if it's password protected, version differences or Mitsubishi supplied special libraries. You can post it here & see if it will convert.

Crossbow, if you read my post you can use DMOV or DEMOV in fact you can also use MOV twice i.e. MOV D0 to D2, & MOV D1 to D3 n FX,or Q if you use only the physical declaration i.e. "D" you can use any of those but as I said monitoring can be a problem as it will display in the format of the actual function.

I have sent you on email, however, you stated you are using a FX3U - 485ADP- bd. This does not do Modbus you need the 485ADP-MB for modbus as it will not generate the CRC for modbus coms.

I think a bit more information is required, for example are you connecting to the programming port, what are you using to recieve data to i.e. GXDeveloper or Works or something else. Remember the programming port (9 pin Din) is 422.

That looks fine but I cannot test it as I do not have the Coms adapter on ly the 232 version. Can you monitor the coms to see if the FX card is sending the correct data.

In your original code picture you have ADPRW[H1, K1, D10 (H3), D100, K1] that is not correct by any means you have K1 where the command code is this should be H3, in the last parameter that should be D100 as it is the destination & where D100 is should be So D10 is the command code H3 (read registers), D11 contains the Start Address & the K1 is how many registers to read. So the code should be ADPRW[H1, D10, D11, K1, D100] If you tried my suggestion post the code so I can check it's correct.

That is not strictly true if using GXDeveloper & not the later GXWorks2 (in label mode) It will still move the data as two 16 bit values even though they are a float see this picture it shows moving a Double (D0 +D1) to another double (D2 + D3) & when displayed as a float it is correct, however, it makes sense to actually use the correct move as it will display correctly in the ladder monitor.

Should be ADPRW[SLAVE ADDR, CMD CODE, MODBUS ADDR, DEVICE COUNT,DEST ADDR] So I would assume ADPRW[H1, H03, H2000, K8, D100] that should put all 8 registers from H2000 to H2007 in D100 to D107 Just be aware though some MB systems have an offset of 1 & some do not. 8193 is H2001