panic mode

i like that sim. bitmask operations would be nice addition 

it is scary to think how many things out there are created by someone not understanding process or architecture of system they worked on. 

not long ago i had to do some work using RS5000 running in vmware15.1. worked like a charm. never had any issues. the possible issue could be that your network adapter is on USB. are you sure there is no lose connection? can you try different adapter or even same one but on different USB port?

which memory cassette? what is the part number? what is the PLC? what programming software version you use?

"Firmware" is set of software loaded into product that is not user changeable. This is done by the "firm" (company) that makes hardware. Unless the firm releases flashing software and image to be loaded onto some product, there is nothing you can do. an example if firmware is PC BIOS. you do not create own BIOS to make the update but you may receive tools and image to upgrade BIOS after some critical bug was fixed - usually something involving security.  VFDs have firmware too and there is no reason for user to change it. same goes for your radio clock, garage door opener, microwave oven, TV or vacuum cleaner.

you do not change firmware. that is what manufacturer does. you only parametrize and use existing functionality as is.  there is a software that can assist with this: https://www.mitsubishielectric.com/fa/products/drv/servo/smerit/mr2/index.html  

exactly... COMx terminals here are the same thing as S/S terminal. btw the second image ("3. Examples of source input wiring") has correct circuit but wrong label next to sensor. it should say PNP sensor instead of NPN.   

sure parameters are the same but.. is the wiring the same? and is the load the same? and is the motion profile the same? if everything is the same then there is a possibility that drive that complains is damaged (internal regen resistor is toasted) according to manual messages are complaining about regen. that occurs when decelerating and motor is working as a generator, dumping energy back into drive. as a result internal DC bus voltage of the drive is increasing. when it reaches dangerous levels you get warnings and faults.  solution is to move smaller load, move slower, stop gently... or make sure to use proper external braking resistor so that drive can burn off the extra energy. there is an internal breaking resistor but it is small and cannot handle much (regen options wired P-D). using external resistor makes it possible to handle more power (regen option, wire resistor to P-C). see page 19 of linked manual.  

you can get ESP8266 for couple of bucks  if you are looking for something more ... DIN-rail style... check Automation Direct https://www.automationdirect.com/adc/search/search?fctype=adc.falcon.search.SearchFormCtrl&cmd=Search&searchquery=mqtt&categoryId=0&TxnNumber=-1&searchqty=10  

selection of components comes after reading all product datasheets and ensuring they are fit for the application.

it you want to communicate with EtherentIP slave you need EthernetIP master.  

Well... Technically you did not need the AOP from KUKA, you can get this from AB since AOP is actually an AB product.  AddOn Profile is AllenBradley software that allows AB products to use one network interface to exchange both safety and standard data with some other product. Before AOP became available, AB PLCs needed two NICs for that. Obviously this was frustrating a lot of users since other PLC brands allowed safety and standard messages over same network interface for very long time. AB was just slow to catch up. Finding AOP on AB website can be frustrating so KUKA simply made the it available on its downloads page. It is just easier to find on KUKA.com by selecting Services > Downloads   Btw KUKA does provide EDS for their controllers. All description files are made available by installing WorkVisual and by default are placed in  C:\Program Files (x86)\KUKA\WorkVisual 6.0\DeviceDescriptions\ And this is what EDS subfolder looks like        

  actually that is something you or our client should define. we do not know how your system is supposed to operate.  btw i do not see any conditioning of the inputs so button press would yield random outcome depending on duration of the press. to make things work the way you want, you need to create one shot logic for each of the buttons. for example consider this part:             IF bttnConveyor1 THEN                 IF NOT in_Sensor1 THEN                 out_Conveyor1:=TRUE;                 ELSE                 out_Conveyor1:=FALSE;                 END_IF             END_IF or just             IF bttnConveyor1 THEN // do something             END_IF consider what happens when "do something" is executed without control. for example replace it with variable increment             IF bttnConveyor1 THEN               myCounter := myCounter + 1; // do something             END_IF this should probably be rewritten into something like this:             IF bttnConveyor1 THEN                 IF NOT bttnConveyor1_was_pressed THEN                     myCounter:=myCounter+1;  // do something                 END_IF             END_IF             bttnConveyor1_was_pressed := bttnConveyor1; the additional static variable ("bttnConveyor1_was_pressed") was simply used to keep record of the past button state and sense the signal edge. in this example rising edge of button press was sensed and used to perform some action ONCE per button press.        

what is "my program"? post the examples. details matter.

If you have a problem with a PLC, simply contact local vendor. If they do not have someone to assist you, they should tell you who can. As stated, many people here are willing to help, but cannot since that is not product they work with.  Troubleshooting using LED status is very limited. You need to go online with PLC and check CPU status and any messages. If you do not have needed tools, and access, you need to get them or find someone that does. 

yup and it is done...

Making wishes is fine. Listing them can be useful feedback if people involved come to read such posts. At any rate that is something that is not going to be resolved quickly. It may happen but will take time  On the other hand there are quite few topics where someone is looking for specific instruction or feature. Well duh ... If we could just talk to PLC and tell it what need to be done, there would be no need to learn programming. Until that day, we may have to keep finding solutions around the limits of used platform. Frankly i see no point in some of the things said. Pointers for example may be not available on purpose. Considering what the PLCs are used for and how poor general programming skills of average automation guy are, i am ok with that... How much memory is used internally by some construct like union etc. is also pointless. Short on memory - restructure your code or use bigger CPU. Programmer may not have choice in instruction set or memory size but has choice in what programming construct is used or not. Don't like it, work around it. And you know the saying:  If you cant beat them, join them.    what i like to do is make my own library that manipulates things the way i like. this also allows me to wrap things around and conceal differences when working with different platforms. and it also helps reduce repetition of code.   

Correct way is to calculate things using very simple highschool physics. Same is repeated in first year of university. Since it us only using basics it us fair game for anyone... And quick way to weed out slackers and wannabes. Knowing water density and weight of tank you get mass of payload. Using mentioned elevation you get potential energy. Using that as work figure and time to do the work you get power. And you want to give yourself some safety margin so you bump that power up ... Say 30%...  Now that you have power and know supply voltage, you can select motor, size fuses and draw simple motor circuit with necessary controls.  Someone that paid attention in school, has basic math skills, has seen motor circuits and has familiarity with applicable standard can do it quickly and show that he is the candidate you want hired. Others can go back to school to catch up or should consider different line of work  The point is that nobody is perfect and knowing or remembering everything. Offering some help us acceptable too. Getting someone trip on derivation or proof of Maxwells equations may trip most candidates and that is not the point   But if someone does not understand the basics, that is not just a red flag, the interview is over. Everyone need to decide what is it that they expect from a candidate.  If you are hiring a programmer and he does not know about data types, difference in passing parameter by value and by reference, arrays, pointers etc. It means he does not know the basics. There is no point in asking him about more advanced topics. My questions are all about the bottom line and things mentioned in candidates resume. No point in asking about things he did not mention. And he better know enough about things that he did mention. Don't mean to crucify the candidate. And will happily accept inexperience, or various gaps. I will give then chance to learn at work (that is expected and required). But i do not tolerate deception. That is my bottom line   

what is the nature of the failure? PSU? status LEDs? this is a really really old product and "new" replacement is just as old - and likely to fail soon as well. if the goal is to give machine new lease on life, i would  consider switching to a new PLC and rewrite the code if old code is available for reference (electronic or paper) or function of PLC is known. granted, this is not everyone's cup of tea... if you want to try populating missing ICs, do not solder them directly to the board, use IC sockets and insert ICs after soldering. it only costs pennies and will make any further swaps much simpler. also check the dip switch configuration, probably want to make it match original. 

this is product review subforum. Post your product review...

Agreed.... I have bunch of different products and - couple of older ones i still use look like that. Those seem to be all built around Prolific PL2300 series chips (or clones) and - fortunately for me, the ones i got are using original chips and working fine. Because there are plenty of fake PL230x chips and while technically those fake chips can work too - all but very old drivers are recognizing them and will not work with them. You can of course try finding and installing some sufficiently old driver version if you are desperate and can find one for your OS but that is not battle you want to be in. Problem is that even if you manage to get around driver certificates etc. your computer updates will be replacing those all the time. Just stick to known good products from reputable sources ... unless you want to be the one to play roulette and find out the hard way. There are of course also fake FTDI chips but in general going with FTDI seem to be a safer way to go. 

why would you want to do that? why not keep it all same? 

you are welcome. also try not to do anything too complex. when things do not work, break them down in smaller pieces and test each independently.  this is what the approach should look like.... create one rung with positive train, then separate one with inverted train. then combine both using some logic (OR) before passing result to an output. output should be used only once when using normal coil. in your case rung 2 (network 2) was always overwriting the output state that was established in previous network. this is why rung 1 had no effect, regardless of value of %M0.1 (controlled by %I0.0).  

very good, now show that PLC who is the boss...  

you need to learn what scan is and how the data changes after each instruction. this will help you understand issue with double coils and why the code acts the way you observe and not the way you want. if i am not mistaken this seem to be the problem and solution.