panic mode
MrPLC Admin-
Content count
3016 -
Joined
-
Last visited
Posts posted by panic mode
-
-
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.
1 person likes this -
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.
3 people like this -
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.
1 person likes this -
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.
1 person likes this -
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
1 person likes this -
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?
-
On 11/7/2022 at 10:59 PM, Inntele said:...turned me into a disabled person, because of which I have to abandon the profession.
wow, sorry to hear that.
On 11/7/2022 at 8:04 AM, pturmel said:They still didn't pay, though.
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.
-
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...
-
-
21 hours ago, Ron_S said:A strange answer with no knowledge.
The equipment was 25 or so years old and was never rented. They laughed when I told them about it
I found it unusual and quite funny so posted it here
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.
1 person likes this -
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
504502. 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.
.thumb.png.8f527b9529c03bd31bbf32ce7876f447.png)
-
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.
.png.ada32e9f2f931ba190426fcd2ed29195.png)
problems with CP1H analog input
in Omron
Posted
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?