panic mode

normally the only reason any output fails is because its specs are exceeded. so either something is connected incorrectly or there is an intermittent problem in the cable or target device. to me this looks like an intermittent problem that causes some short (not necessarily GND, could be also the 24VDC etc.). if the root problem is not found, switching to another output will just lead to inevitable - again and again. the analog output card are not cheap.... adding an isolator should protect the PLC analog output but the isolator itself may still be damaged if problem is not fixed. but since you have already replaced both cable and the positioner, this is most likely fixed - hopefully permanently. i would still be inspecting the entire length of the removed cable and each and every termination as well as the old positioner. if this does not yield results, there is a good chance the same thing will happen again. and if that is he case i would probably consider adding in some extra protection... About protection: the datasheet for Q68DAIN shows that load can be 0-600 Ohm. so zero Ohm load is ok. it also stated that short circuit protection is available. So short to DC common is not a reason that outputs were failing. It must be something else. And that something else could be another circuit... Normally analog IO are using shielded cables and they tend to be done with single cable from PLC to the target device, with shield connected to ground and DC common in one place (at the PLC cabinet). This is pretty much the practice we used on numerous projects, some with thousands of analog IO points and very long cable runs, never had an issue (used to do controls for chemical plants). But when that is not the case, the best bet is to scrutinize the wiring methods. Any split (multiple cable sections, shared terminal strips, shared multiconductor cables, routing near power cables or sources of EMI etc) is potential problem and therefore a red flag that requires closer look. good luck...

?

maybe so but i have been asked before (twice to be exact) to do same thing on equipment with another brand of PLC+HMI. when i saw the message i asked them for proof of ownership, which of course they did not have, so i walked away. if they did not want to pay someone else, why should i expect they would pay me? and why get involved into something that may turn ugly and violate some property rights? but you are welcome to do your own thing, i have plenty of work with nice people, don't need to wrestle with pigs or possibly engage in theft.

this is something used to rent equipment and ensure payments are in. clearly this is not something that author wanted others to touch, so why get involved? if something on equipment fails, then company that owns equipment will be the one to deal with repair/replacement.

Mitsubishi makes expansion module for it (FX3U-4AD-TC-ADP) but not sure if this can work on the clones or how much convincing it would take. low level interfaces like SPI, I2C etc are used for chip-to-chip communication, this is meant to be interfaced directly to MCU and exchange data serially at high speed. PLCs are different animal and may not have suitable GPIO exposed... and i see no interface on that board, everything is already conditioned to appear as PLC IO. then there is an issue of a missing driver. One could still choose to use PLC IO but in general they are operating at different voltage levels so hardware interface adapter (level shifting) is needed. Plus PLC IO are way slower than MCU GPIO. I have still used this on occasion to interface some industrial controller to otherwise incompatible devices. it can work but it requires one to write own code and as mentioned, this is a crutch and tend to be painfully slow. For temperature this may not be an issue as temperature changes are among the slow processes. Good luck... BTW, there is tons of online resources on SPI, this is one of simple interfaces that can be easily implemented even on platforms that do not include hardware port for it. Finally, your version is MT (transistor output) so it is tempting to use them as PTO but the issue is that high speed inputs are simply counting received bits, not storing/shifting the value. In other words - slow it is. You just need two outputs and one input. Input is used to read the data from chip. Outputs are used to select chip (also works as reset) and send clock. on every clock sent you need to read the bit. in this case there are only 16 bits to read. if your PLC scan time is 10ms, you can create clock with 20ms period or 50Hz. So theoretically you can read the temperature value in 18*20ms=360ms which is not too bad...

TCP connection from a client to a modbus server only needs IP address of the server. Port is always 504 502. Server is always supposed to run. Clients can connect, exchange messages and eventually close connection. Same is with this forum. it runs on a server. if the server is down you cannot use the forum (your web browser is a client). Inside PLC, modbus server instruction has fields for transmitted data (read/write).

here is an example of "internal circuit" and operation of one safety module https://www.utmel.com/blog/categories/relays/what-is-safety-relay but... this is not the real internal circuit. it is a simplification used to explain how it works. for example it does not have second channel depicted and shown circuit has no way to detect cross channel faults. The better version is shown for Omron G9S301 or G9S501 and it used to be shown on the side of the module. here is another "approximation" of such circuit. note, while this does show both channels etc., this too is not able to detect cross channel fault. also note that fuse is a key component of such designs (need to be a fuse and not circuit breaker). on some products like G9S it may be even accessible.

individual safety relays can be used as atomic(low level) building blocks to make own safety products but you need to follow the guidelines and design the circuit for certain functionality yourself or implement existing one if found (two hand control, EStop control, light curtain control, safety mat control...). word of warning, there is a reason one does not do that any more and instead buys ready to use modules. the first and most obvious one is that such designs need specialized knowledge that goes well beyond following instructions in a datasheet of ready made module. also this need to meet safety standards and be independently tested by approved labs. one can see examples of that in many older products (FE207 board in KUKA KRC1, ESC board in KRC2 etc.). and as already stated doing things like that is absurd unless dealing with huge volume. so today, groups of individual safety relays are used at most for contact expansion for ready made safety products (that already have all functionality and approvals). even there, one would really need to think hard about using individual relays rather than ready made expansion modules. another issue is that products like SR103AM0 are only meant for the very simplest uses (monitoring or control of a single safety point). typical cell likely may need to use dozens of them (or more) so very often this is just not practical. that is why there are safety networks. they allow one master (usually a safety PLC) to connect to numerous safety devices, even those that are complex on their own. an example is safety PLC monitoring some production line with many cells, each cell containing one or more robots, own PLCs and dozens of safety devices. there are some hybrid products for different scales but ... safety modules like SR103AM0 are the lowest building blocks currently on the market that would allow you to make circuit without need for lab evaluation and certification. so the best you can do that i am aware of is to have product that is easy to find and replace. for example you can have them with removable terminal blocks. that way you can build own wiring assemblies that allow quick connection between safety module and your board.

yup... when troubleshooting data exchange issue it is a good idea to see both sent and received values in hexadecimal format. that will quickly identify any discrepancy in endianness. the other option could be that values are inverted... unfortunately documentation is not explicit of used format and no sample value is shown so this means more legwork identifying what the value format really is. can you post one or two sample values (preferably in hex) and actual sensing distance (expected value)?

also note that comma separator is still needed when no checksum is sent (see 3.9 Loopback example) so the message should be 02,0204,64,11,128, followed by ENTER, Loopback can be used to scan network for attached nodes.

no response at all? i would check wiring, terminations, baud rate, correct node address...

this is what i would try: 02,0204,64,11,128,00 followed by ENTER

no idea... i would try all options. i think manual mentioned that checksum is options but it did not specify if it is to be omitted or populated with something random like "00" so you will have to try. my main point is that termination was incorrect and instruction was likely rejected because of that, even if correct CRLF is encountered after that... this really should be quick and easy to try. now that i think of it, it is probably needed (same fixed format) but value is simply not evaluated by device. so your message looks ok other than CRLF. other than i would question if COM port settings match the target or if wiring is correct. Are you getting any response back? if so what does it look like? if you do not get anything back, chances are that wiring is incorrect. if replies are garbled, then port setting config is not right (wrong baud rate, data bits etc.). also are you sure that node address of target device is correct (2?)

btw manual shows that too:

changing hardware for a newer may be a smart idea to avoid obsolence but it will come with a cost (hardware and programming) and will not change anything if message is in wrong format. and i think that is what you are dealing with...just checked your post closer and see this: The "CR LF" is supposed to be just a pair of characters (only 2 bytes), but based on your screenshots you have entered it as string of 5 characters. also since you are sending message without checksum, the last comma is likely also not needed... (maybe) CRLF is normally added when you type command using keyboard and hit ENTER. CR is Carriage Return and has value 0x0D LF is Line Feed as has value 0x0A in a file you would need to do the same so that next line is shown (see lines 3 and 4) for more details change view to show all characters and you will see why.

go to properties, settings, ascii setup

it's been a while since i used Omron and FINS. maybe there is something newer too but did you try Google: https://www.google.com/search?hl=en&as_q=c%23+omron

the masking operation need to use AND, not XOR... XOR with 0xFF would change 'G' (value 0x47) to value 0xB8 which is not what you want. in fact one may probably want this value to be a non-zero since zero may be seen as end of string. so space character would likely be safe choice... (setting that would need an OR instruction)

"it is simple" does not describe it... why don't you post your code and explain your test method or how to reproduce it? what is connected to X0 and X1? are you sure that logic is scanned? are you sure that M100 is not used anywhere else? did you try some other bit instead of M100 to make sure it is unused?

nice

That is a great idea... And so simple. To

i have never uses that robot but based on quick internet search it seem to be a small robot arm (scara). btw. AWC board is not just an Etherent card... it is an entire motherboard (controller) with a lot of functionality. Did you follow the instructions in the manual on replacement? flash card is substitute for a HDD and contains OS etc. but key system settings (robot serial number, licenses etc.) are stored in NVRAM. when AWC is replaced, all settings need to be transferred, that includes flash card, NVRAM, address configuration... not sure what the "protection error" message is but may as well be complaint about missing license. Adept MV Controller.pdf

you can have bunch of HMI buttons, each setting different bit in some memory area. at the end of PLC scan you can let PLC reset the entire area. for the rest of your PLC code, each of the bits will be seen as one shot. that will work rather nicely for plenty of cases and it is very efficient (no timers, very simple logic, no way to stay stuck etc.). if for some reason write message was missed, user would see no response and simply repeat pressing the same button. but while simple, this does not work in all cases. an example is where you want to use button to jog axis (and releasing button is suppose to stop the jog). in that case one can resort to some alternative to make it robust. one simple way to get around this is to have HMI cyclically write entire block of memory. this way even if one message is missed and thus desired change is not seen by PLC, the very next message will overwrite the entire block and correct the situation. this is pretty much of how fieldbus data transfer works so all received signals seem to be continuous and instantaneous. this is also quick to implement when one is making custom HMI (a PC application using own driver or implementing just two functions of some SDK - read one memory block and write another...). but this is not how most HMIs work since it is limiting (all write requests need to be in one block). but typical controller may have many different memory areas (timer, counters, inputs, outputs, memory bits, data registers, retentive memory locations etc) they would normally send commands as individual writes to each individual location. so number, size and type of write messages would always differ. therefore one may dig into the bag of tricks and do something fancy depending on particular platform capabilities. and as you have already stated - if something is really critical, it should be handled as such and use more reliable solution. for example robots are making use of enabling switch (a safety device) allowing user to stop any motion command even if jog button was to fail.

ACE3600 ?

maybe... did you check the instruction list? and you should always post your code and expectations. (resolution, time span, accuracy...) if i read this right you have a problem due summation since average is computed by: AVG(n) = (X1+X2+...Xn)/n it appears that you are attempting to store top side of the fraction into one variable and of course this will overflow pretty soon. solution to not do that... note that the very next average will be AVG(n+1) = (X1+X2+...Xn+1)/(n+1) but this can also be written as this (isolate last term) AVG(n+1) = (X1+X2+...Xn)/(n+1) + Xn+1/(n+1) or AVG(n+1) = (AVG(n)*n + Xn+1)/(n+1) but that will overflow the same way as before due multiplication AVG(n)*n. however this can be rewritten as AVG(n+1) = AVG(n)*n/(n+1) + Xn+1/(n+1) where AVG(n) is previous average, Xn+1 is the latest sample, and "n+1" is the latest sample count. as long as you compute n/(n+1) before multiplying AVG(n), there should be no problem since n/(n+1) will grow but never exceed 1. ultimately this will settle at some average value since limit of Xn/n goes to zero as n goes to infinity so adding more samples will just add zeroes and average will stop changing. this begs question... are you really really sure you need total average over indeterminate and always increasing time interval and not average of several most recent samples? one would normally look at average only over fixed number of samples. that number can be small or large but it should be fixed. if you really want to cover "endless" interval, you need to define what is "endless".