panic mode

get the programming manual and check it out https://www3.panasonic.biz/ac/e/dl/manual/index.jsp?series_cd=1700 looks like FP0R has bunch of timers and can be used with different increments - 0.01s or 0.1s or 1s. using 1s base (TMY) you can have timer run for just over 9h.

please do not use wrong name - you are only confusing yourself and perhaps those who try to help you. that is clearly not a hyperterminal - screenshot shows that this is the KRterm from Kawasaki. while features/settings will overlap (at least the core), they are not identical (may look differently, be called differently, etc). this is hyperterminal and how the settings appear:: any terminal software allows you to configure some things including termination characters. so this may already be there... there seem to be configuration software for the product. did you use it? it should allow you to confirm or set specific com port settings and everything else that product may need. without correct cable and com port settings, there will be nothing going on. so what port settings, what cable are used. and are you even sure that you are connecting to a correct port? at least some of the devices seem to have more than one port. AD has bunch of examples including documentation that dives into every command. your posts suggest that you only look at ViewMarq itself for response. what about getting response though communication channel that you are trying to use? for example why not ask it to report version? that should allow confirming cable, port and port settings are correct even before you send some longer command in correct format (one that may specify correct window, position, blink etc.) personally i like RealTerm because one can see the messages in different formats - including hexadecimal. as someone who wrote code talking to various devices, hexadecimal view is essential debugging and understanding what goes on. this is also the reason to always have ASCII table at your fingertips:. in this case you only need carriage return which is already explained has code 0x0d or 13. Btw, that is inserted as you are done with typing of the command, or more specifically when you press Enter. For example if you are using Notepad++ to write anything, try turning on "Show all character" and you will see everything - including tabs Cariage Return, Line Feed etc.

as shown, both source and destination are already array elements. so by controlling index on both ends, one can transfer data any way you like. index is the value inside square brackets. this value can be hardcoded like in your example or it could be a pair of variables that you control

i think last time those were made was in the 70s. they may be falling apart on their own, without user touching them. why not use something more recent like HMI? you get way more bang for the buck... or use panel mount LED/LCD counter module as a display, together with encoder or pair of buttons (increment/decrement) as input.

it is the same thing you do when adding numbers by hand using nothing but a pen and paper. for example adding 597 and 895 597 895 (+) ------ ???? so you start from the right side (least significant digit) and add those values 7+5 = 12. so you write down 2 (result is ___2)and remember to carry 1 (representing 10 actually) to the next position. then you are adding 9+9 but also must include value that was carried over (1) so sum here is really 9+9+1 = 19, and you write down 9 (result is __92), and carry 1 again. then you have 8+5 and since we still carry value from previous digit addition, it becomes 8+5+1=14. so you write down 4 (result now is _492) and you continue to to next position. since there is no more digits in the operands, we just have the carry (1). we write this down and result is 1492. if this was clear, you should have no problem adding numbers that have many more digits. same is with the computers - they can only handle limited chunks of data (based on instruction type and size of registers). so to break free from this limitation and be able to handle even very large values, carry value need to be considered. and programming manual has the nice example as well. before calculation one would reset the carry flag. setting flag is possible too but this is used less frequently

can you please just get to the point and tell us something about function you need: 1. what is the exact PLC model 2. what is the PLC software type and version 3. what is output really supposed to do if you want to make single 1sec pulse when button is pressed, and really make it 1sec pulse regardless how long the button was held down, something like this should do explanation X5 is input for push button (trigger). instruction is not a standard NO contact but senses rising edge (hence the arrow up). this ensures that regardless how long button is press down, only single pulse will be generated. rest is a simple seal-in logic: output Y4 is held on until timer T4 times out. K10 is duration (10x base time). on most timer base is usually 0.1 seconds. so 10x 0.1sec = 1 sec.

What is the CPU type? That will determine instruction set. Then you can check what options are available - there could be suitable instructions for this... But you can always manipulate data yourself. For example to extract lower byte, just AND the value with 255. To get the upper byte use swap instruction then again and the value with 255.

when it comes to Ethernet/IP, AOP is used to allow single network interface to be used both for standard and CipSafety data. one can of course choose to not use AOP for this then one needs additional network card. it is same as working on PLCs with older firmware.

post your code. are you checking error flags (A434.xx)? are you measuring current with a multimeter to confirm it is really in that range?

add card into PLC rack and note the head address. perform correct DNET wiring and termination. just like other fieldbus types: a) all nodes are wired "in parallel" (hence the bus). b) on the two extreme ends of the bus need suitable terminations (121 Ohm 1% resistors). c) while it is possible to use trunk/drop style wiring, there are limitations, particularly on length of the drop. Preferred way is to have no drops. d) all nodes need unique address or MacID e) data exchange for the most part is cyclical (master is polling slaves). in rare instances there may be need for explicit message. normally this is used to configure slave or transfer large block of data that exceeds size of mapped IO blocks. note unlike other bus types (ProfiBus etc.): a) DeviceNet bus also has conductors for power and you need to provide that 24VDC (it is not something that is obtained internally). b) terminating resistors are normally discrete components and resistor leads tend to be exposed - it is a good idea to add protection (i prefer clear heatshrink). On other busses they tend to be integrated into connectors or molded into suitable shape. c) Unlike Profibus for example, bus speed settings is usually done at each and every node, although there are some products that can autodetect baud rate. next part is software configuration. this means obtaining EDS for each slave. contact slave manufacturer to get them. according to JXCD1 manual, EDS can be downloaded from the SMC website: https://www.smcworld.com/upfiles/etc/international/imm/JXCD1-TF2Z195.pdf i just glanced it and see IODD file for IO-Link but not EDS so perhaps specify exact product name (JXCD1S or whatever) or call tech support. on second look, one just needed a minute or so do deeper search specifically for DeviceNet version and EDS file is found at: https://www.smcworld.com/manual/en-jp/?k=JXCD1 or direct link https://www.smcworld.com/assets/manual/other/files/jxcd1_v11.zip then the master need to be configured by building scan list. have not done this on Mitsubishi so cannot help much there. the idea is to add matching EDS for each slave to master configuration and parametrize it. in simplest case that means stating the node address but you may also need to specify size of IO blocks that node will send or receive. Finally there will be some code. Normally this is just few lines to initiate data exchange and handle diagnostics (missing slave etc.) and of course do the data exchange between master and controller. Normally all of this (including code examples) is in the product manual. In Mitsubishi tradition, programming documentation tends to show examples for intelligent modules using head address zero and you would of course need to change it to match your PLC configuration. if you are new and confused by this, perhaps consider placing this module next to CPU. for more help or interpreting data in the documentation, post the links to actual manual(s) so we don't need to look them up. example ps://ca01.smcworld.com/catalog/New-products-en/mpv/es100-141-JXC/data/es100-141-JXC.pdf <EDIT> and AndreasW already posted link to Mitsi manual.

lowering baud rate does improve signal integrity. this is obvious even from reading installation guide, since it is possible to have longer bus network if the baud rate is lowered. this is not disputed. cables have capacitance and inductance so they can distort the signal. this is why bus is to be treated as a transmission line which is the reason for correct termination. and it looks like you did receive product that is forcing you to use different settings. sometimes that is all one can do. fortunately this is pretty rare.

just about all problems with DeviceNet that i have seen were due to wiring. even people that do not understand networking manage to find configuration that works, even if takes bunch of attempts. but when something is wrong with the hardware (wiring, termination ,shielding) no amount of poking at settings will get you though. since the line was working before, and you are backing up and restoring settings, there is no reason to doubt parameter settings. lowering baud rate is usually last ditch effort. Sometimes it may help but there are no guaranties. one example where that does work is if one or more of devices use autodetection of baud rate. on a noisy network they may have better chance when baud rate is reduced. as for troubleshooting tips, i would say if not already done so try following: measure resistance across data lines to confirm it is 60 Ohm (pair of 120 Ohm resistors in parallel). if not correct, one of the terminators is not connected or there is a lose connection on one of the bus lines. it could also be that the bus is over-terminated (more than two terminators present). check voltages at each node on every terminal with respect to black wire. should be about 2.4V on blue wire, about 2.5V on white, 0V on shield and 24V on red. check if the bus is really a bus topology. if there are dropped nodes, check the cable length of the drops. drops need to be short, do not remember the specs but if i recall they should not be more than 3m or so. check if the bus shield is grounded at ONE place only. if the cable was damaged (jacket has abrasions, punctures by metal chips etc) because it may be acting as a second grounding point and ground loops will have terrible effect on signal integrity. also check cable routing. communication cables should be always routed away from sources of noise. if possible try to shorten bus (just for testing) to see of the problem persists. this is one thing that is done nicely on ProfiBus - just move terminator switch on any node in the middle of the bus and (if the bus is wired correctly) that is the only hardware change. doing so on DeviceNet is a bit more effort.

yes, rolling own code is not hard but there are limitations. which is why recipes are normally HMI functionality as they tend to have more memory and response time is less critical.

don't know those platforms but some may have the function for that and if not the idea is to make an array of records - if the controller supports user defined structures. if that is also not available, just use parallel arrays of suitable type and size.

whatever platform you are working with, you need to have your reference documents for that platform at your fingertips. and SLC500 is no different. https://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1747-rm001_-en-p.pdf SLC supports indirect addressing so it is not a problem to access register using an index. it is same as using an array. suppose you values are in table N27 and index value is in N7:34 and the result is in N7:35, you can use something like SCP I4:0 3277 32767 0 250 N7:34; scale analog input with raw values range 3277-32767 to an engineering units 0-250 ton and place result into N7:34 MOV N27:[N7:34] N7:35; get value from lookup table N27 and put result into N7:35 based on scaled analog input value but... using the integer data table as a lookup table to get result means you only have 250 values that can be displayed (no decimals). and while that may be sufficient and meet your application requirements, it does sounds pretty low resolution compared to what one normally gets from the sensor.

did not use Fanuc in ages but there can be some differences: as i recall Fanuc robots only use two stop types (0 and 2). stop 2 is a programmed (controlled) stop which is when robot reaches target point while controlled by program. stop 0 is used in case of an error or fault or safety stop (estop, fence etc). in case of stop 2, robot should always be on path - regardless if stopped or not. in case of stop 0, brakes are applied and motors are deadlocked (short circuit breaking). so from this moment on and until robot comes to a rest, robot is actually out of control and possibly no longer on path. think of one axis as a car without ABS that was moving fast and then wheels are locked... as expected, car will slide in the general direction in which it was traveling. some cars may remain on the road, some may end up in the ditch, its hard to give precise prediction... now back to the robot. each axis is another car. and each is different. so each will decelerate on its own depending on torques acting on it and obviously this depends on many factors: robot type, assigned payload, actual payload, pose, speed and trajectory at the moment of interruption, number of axes in motion, coefficients of friction, state (wear) of the individual brakes, gear ratio at each axis etc. so the place where robot actually ends up will be more complicated because EOAT depends on position of all joints. but it will still be in the general direction in which was moving initially. the question here is how the recovery works and that is something that may be product or brand specific so check the documentation, ask Fanuc or test. Nowadays I work with KUKA which also supports stop 1, and that means more complex behavior. Naturally there are more possibilities where the robot may end up in the case of stop. One nice feature here is that KUKA will always do a BCO if not on path. This function is moving robot at reduced velocity until on path, then stops and waits for another start. The exception is the EXT mode which does not do a BCO. This is type of auto mode in which robot is controlled by something external (PLC), equivalent to using PNS on Fanuc. So in this mode, blindly clearing faults and issuing start will make robot move like before - without BCO and without speed reduction (even if not on path). Obviously when commissioning/programming is not done correctly this could be a problem. For example PLC does not see if robot is on path or not on its own, so blindly issuing another start in EXT is a great way to create a lot of carnage. Which is why KUKA recommends to stick with manual recovery in T1. This makes sense since auto recovery needs proper solution and here - attention to detail is pretty important.

acquiring another skill is always a plus and you never know when it will be handy. more importantly, continuous learning helps one be flexible and open to change. i have worked with many PLC brands (AB, Siemens, Mitsubishi, Omron, Beckhoff, Schneider, etc.). knowing any one of them would be more than enough to keep me busy and employable but that never stopped me from trying to learn more while trying to retain as much as possible. as a result PLCs are important but only a part of what i am good at. i like learning and and would not change a thing. knowing more gives me the edge. also there is a freedom to choose even when things get hard and others may be struggling to just stay afloat. when there is a shakedown, first to go are the temp workers and those with limited skill set. and i have seen many people come and go, while i move when it suits me - salary, benefits, hours, travel, work climate, location, etc. so everyone has unique needs and should decide what works for them. if you think it is the best for you to move on, don't let others stand in your way. change can be good but even if there is a regret, it is better to be because of own choice, than someone else's influence.

so doing 4 or 5 passes can give you X axis range of 880-1100mm so some measurements are needed to verify data transfer, PLC scan time, IO refresh time and valve response time. modern PLCs are quire fast, Ethernet messages are not big deal if you transfer data in reasonably sized chunks. transferring all at once requires a lot of memory and also it is going to take long time. Depending on used platform and implementation details streaming may or may not be perfect because you also need to take care of pretty tight timing on numerous outputs. the PLC logic should be fast. this means not dealing with valves individually (bit by bit). it would be better to use block move to write data to all outputs at once, wait a bit (make this adjustable), then clear all outputs the same way. and this could be done in an interrupt to get best possible accuracy. If the streaming of data does produce issues (scan time glitches and inaccuracies in the print) one options is to simply not transmit while print is in progress. In this case you would need to transfer and buffer all the data for that one full pass in Y-direction and this is done every time before the Y axis moves - transfer would take place while X axis is moving because no print is in progress at that time. that means you would need to transfer and buffer 11bytes * 400 samples = 4400 bytes or 2200 words. all of this is very doable.

i am not quire sure i understand the details of what you are trying to do. for example what is the total work area (length of X/Z)? that could explain why would data file need to be so large. 20mb grouped in 16bit points means up tp 10485760 points or canvas of 3238x3238 pixels. so yeah.. to me it sounds like you are developing something that paints murals or billboards and the 88 valves are an array of spray nozzles for different colors. if so then why not use just few of them (CMYK or RGBWK) instead of 88. also 16bit value is sufficient to control 16 points but it is not sufficient for addressing 88 valves that you require. that would require 88bit (or 96 bit). conventional industrial PLCs are not very good for this. one of the limitations is scan speed as well as IO speed. also most PLCs would have hard time with that large data file but chances are things can be optimized. so getting to know real requirement is the key. next one need to focus on hardware. perhaps there is no need to dump entire file to PLC - how about sending enough of data for one line scan only? if commercially available products do not meet the needs, one can make custom hardware to do pretty much anything.

spring only gets to do something after there is no more current in the coil (magnetic field collapses). as long as coil is energized, spring is not in control. so after output is off, current still flows through solenoid (but now it is going through diode, not the output). this is due energy stored in solenoid and duration is affected by characteristics of suppression device. and as mentioned already, connecting MOV or Zener across solenoid will not produce any meaningful difference if output has own built in diode (and normally they do!). and if not but you choose MOV and Zener with too high breakdown voltage, the output device will get damaged.

a very good point, i would add that MOVs do not apply reverse voltage, they are passive component and do not store energy - they just conduct more at some higher voltage. depending on used product, this value is different. the higher the clamping voltage is, the shorter the pulse is (turns of faster). diode has Vf of only 0.7V so the clipping on 24V solenoid occurs at 24.7V. That is extremely low and takes longer to switch off. But with MOV it may be at 36V or so. using Zener diodes one can get the same effect which is why there are several options to choose from.

exactly

and just got call back from support. i was told that this is a known and not fixed issue in version 2019. one should consider upgrading SWE to 2022. how convenient...

Hello everyone, have not done panel design in a long time, I am not used to SWE, was using other products in the past. and actually everything is going well expect when trying to insert 3-level terminal blocks. single and two level terminals work fine, issue i am facing only appears with 3 level blocks: while only one of three level is used, things are still ok. but for some reason as soon as another level is used, SWE interconnects all three levels (making them same equipotential) then adds further and non existing levels (4th, 5th...). at first i thought something was wrong with the parts i defined but the same happens with any 3-level block. any ideas?

wow, sorry to hear that. and that is why such measures exist, someone was burned before. which is why i consider any tampering with such measures equal to theft. hence do not want to be part of it.