DanW

MrPLC Member
  • Content count

    314
  • Joined

  • Last visited

Community Reputation

20 Excellent

1 Follower

About DanW

  • Rank
    instrument guy

Contact Methods

  • Website URL http://
  • ICQ 0

Profile Information

  • Gender Male
  • Location Midwest, USA
  • Country United States

Recent Profile Visitors

4836 profile views
  1. Display a HEX value as floating

    Is it the best way?  I don't know.   Does it matter how fast the conversion is? I do know that there four different word/byte (IEE754) formats for 32 bit floating point values, two of which are commonly used in Modbus. Many Modbus master/clients provide the ability to pick one of the two to use to interpret the raw data. If your master/client has a choice for floating point formats, you could try the alternative one and see if it does the conversion properly with the raw data, before moving the data.
  2. Display a HEX value as floating

    If it sorts inversely, then move the data words to change their order of the 16 bit data words and convert to float D0: BE62   move to D2 D1: 31D7   stays in D1 D1: 31D7 D2: BE62 new inverse of the sequential data D1 D2 is BE6231D7; convert D1 D2 to the correct float
  3. The format shown in the 5th screen shot (2.4) is a Modbus RTU query and response, so I would expect that reading the three values can be accomplished with a Modbus instruction.   The advantage of using a commercial Modbus firmware/routine is that the nitty gritty of stuff like calculating the CRC already done for you.   In fact the following screen shot mentions Modbus.   The data field in the answer is not correct.   It says 3 bytes, but shows 6 bytes (3 registers).   The Modbus Function Code 06 is normally a "write single 16 bit register", so you'd have to write each register value one at a time with separate 'transactions'.  I suspect it'll work, however, I have zero experience with either master or slave.
  4. I would try turning off CTS control (Port 2 settings) I have no idea what 1:N protocol is, do you? Given how close it is to Modbus, can you try Modbus RTU protocol?
  5. You shouldn't split threads, because people won't see both. I don't know what cx protocol is, but some RS-485 devices need physical jumpering for half duplex operation - where the Tx negative is jumpered to Rx negative, Tx positive is jumpered to Rx positive.  
  6. It uses the Modbus RTU 'read Holding register' message format, so the stuff that creates a 'can't connect' Modbus RTU situation applies. Here's my list, if it doesn't apply, like the multidrop items, skip it. Modbus RTU over RS-485 'can't connect' issues: - do both ends have Modbus installed and enabled ? (Modbus frequently an option)  RS-485 is NOT Modbus, it is a hardware bus. - Right protocol?  RTU or ASCII protocol being used? - neither is compatible with the other - is slave field device powered, connected and on-line? - Correct pin-out for RS-485 on an RJ-45 or DB-9 connector, or any non-screw terminal connector? - DB9 gender changer adapter is a null modem adapter - DB9 shell is grounded, common mode pulls down the network - RJ11/12/DB9 adapter wiring is faulty, wrong, missing - RS-485 cabling connected and integral for entire run? - use of non-shielded, non-twisted pair cable - serial settings identical on both ends? RTU uses 8 bit data word, 1 start bit, 1 stop bit, parity?  2 stop bits can be a no-go;  ASCII 7 bit data word - has the power been cycled after serial comm settings were configured to force the recognition of the changes? - RS-485 A/B driver lines backwards.  Even though should be (+) to (+), (-) to (-), labeling is not consistent vendor to vendor.  Try swapping the A/B driver lines. - serial port powered 232/485 adapters on laptops frequently fail to operate if not powered by external supply because laptop serial ports limit power to the serial port to conserver laptop battery power - Using the wrong COM port - USB/485 converter installed on virtual COM port - check Windows' Device Manager > ports - RS-485 signal ground is case ground - excessive common mode swamps the RS-485 signal.  Solution - RS-485 isolator/repeater module - lack of 3rd wire signal ground causes common mode fault - older 485 signal driver can not handle the number of multidrop nodes - more recent vintage USB-485 converters do NOT jumper Tx(-) to Rx(-), Tx(+) to Rx(+), check wiring - 232-485 converter DIP switch settings for serial or soldered resistor for intercharacter delay - faulted driver is locking up the network - one device can pull down an entire multidrop network - two or more masters on an RS-485 network will fail - PDU collisions - master time-out set to infinity - lack of comm to one faulted slave on a multidrop locks master into infinite wait for something is going to happen - bus wiring issues - junction box misconnection, JB flooded, shield continuity broken at JB, stranded wire whisker shorts - cabling run exceeds the capability of RS-485 for distance vs baud rate.   The 1200m max spec does not apply to baud rates > 90k. - stub wiring at multidrop nodes causing reflections which create 'noise', false data bits. - Added biasing resistors load the drivers - terminating resistor somewhere other than the 485 bus end nodes - attempted full duplex operation for a protocol that is by design, a half duplex protocol - addressing the wrong slave, getting someone else's reply, or no reply if there is no slave at that address - slave node ID can NOT be 00.  Master uses 00 to broadcast a message to which a slave is not to reply - electrical noise on the data lines causes fake start bits, continuous errors, real data never gets through    
  7. 50+ Thermistors on PLC

    Thanks for pointing out Automation Direct's several different thermistor input cards.   Not a lot of vendors offer a thermistor card.
  8. 50+ Thermistors on PLC

    Presumably you want temperature units. There are not a lot of resistance-to-4-20ma transmitters that linearize to a thermistor curve.  The one I know of is Acromag's TT230, a single channel thermistor transmitter that has "Customizable thermistor linearization table with preset curves for popular resistances".   A PAC I use has an 8 channel RTD input card that has several straight resistance input ranges, 0-200, 0-500, 0-1000, 0-2000, and 0-4000 ohms with programmable look-up table functionality for conversion to temperature units. I suspect that most RTD input cards have some configurable resistance input option, but you'd have to investigate. Considerations when using a multiplexor Synchronizing an external multiplexor to the input scan of a PLC could be a challenge if the Mux is not driven by an external pulse.   A mux's solid state switch (as opposed to dry contact switching) might not be designed for switching resistance and affect the measurement.
  9. OMRON CJ2M-AD08V1 - AD data fluctuation

    That will certainly work but now you have to activate 2 switches. 13/14 is SPST.  If it were SPDT with another terminal for the open position (as shown), say 13/14/15 then with only one activation you could ground the input through the unpowered 10K pot which is effectively a grounded input which should give you zero volts (I'd try it just to make sure that is doesn't draw a bias current somewhere and give you an offset).  
  10. OMRON CJ2M-AD08V1 - AD data fluctuation

    Apparently a high value during the open circuit state is not acceptable?  What is acceptable, zero volts? Your AI will show 0 volts when shorted. What about using a SPDT switch where the terminal shown as the open switch state connects to the AI (+) input, so that when the switch is open the AI (+) is shorted to V (-), but when switch toggles the AI reads the pot voltage drop as shown?
  11. There is a category of software for dealing with process data from controllers known as HMI software.    HMI software is designed to talk to controllers through Modbus or OPC, get data from a controller/box via Modbus or OPC, put data into a database, trend the data as Y-t charts, and since it's usually a Windows app/service, it has the power to do custom programmed analysis. Every PLC vendor has their own branded HMI softare, then there are 3rd party HMI software vendors like Wonderware, Advanced HMI, Ignition, or Indusoft that are OPC clients out-of-the box, so they talk to OPC servers.    The OPC client will most likely have Modbus driver in its OPC client.  If not, one buys the Modbus license for it. The software package is a toolbox of development software, a blank slate that needs to be programmed.   One buys a run-time license for the developed program.   But none of the generic HMI software packages come with pre-programmed, high level software analysis of process (vibration, in this case), that's the job of the integrator/programmer.
  12. OMRON CJ2M-AD08V1 - AD data fluctuation

    1. Why are there switches (rectangle with a lever arm is a switch?) in an analog input circuit ? 2.  Are these 8 signals current signals or voltage signals? 3.  What are the field signal generators?   pure current through a variable resistance?   output of a transmitter?   4.  What is an A/L screen?  If it's the cable shield, then connect it to chassis ground, not to the AI (-) 5.  The video appears to show some high count value toggling with the value 0.  Is that a correct interpretation? Is that happening with the switches in the open state? If the switches close, what happens?
  13. OK, now I have a better understanding your thread title, "How to make a PLC Device accept data exported from Application Software." Vibration is one of those vertical knowledge categories that is so 'expert' related and sophisticated that I consider a category for which Artificial Intelligence might bring some value.   Ordinary people do not have the experience to interpret changes-over-time of frequency domain FFT charts (nor do most have the desire).   After sitting through a Bently Nevada presentation some years ago, it impressed me that the analysis of vibration and its related data is something for dedicated, expert, specialized software that relies on expert knowledge and years of experience in the field. As I mentioned before, a PLC is real-time industral controller, it is NOT designed as an analysis platform.   This forum or another like once had a thread asking about trying to do FFT's (Fast Fourier Transforms, time domain to frequency domain conversion, a key element in vibration analysis) and the response was, no! a PLC is the wrong platform for running FFTs. If the application software is sophisticated enough to determine that a motor should be shut down, then writing a value to a PLC programmed to recognize that value and interpret the value as "shut down motor #x", then a PLC brings some value to the party. But if the application software already generates a report that tells you "conditions at motor #x reflect the need for shutdown and maintenance, maybe even to the level of "maintenance on bearings 13B and 14A", then it takes human beings to implement the sequence of tasks needed to do that, sequential steps like - scheduling  (when can the motor and what it is driving be shut down) - checking inventory for the needed parts (bearing, gaskets, whatever) and ordering if need be (and how does that affect scheduling?) - issuance of a work order and who does the work (contractor, staff?) - motor shutdown - LOTO - actual work - barriers, wrenches, pullers and the guys who do that all of those steps involve humans doing things that PLC's don't do.  The PLC might only be involved in the shutdown part; PLC's do not issue work orders or check inventory. So, what kind of data is the app software exporting? A.  Data that needs further analysis (probably a task for more sophisticated software, not a human, unless you've got vibration experts on staff)? If you need data exported for further analysis, then you need to find such expert software that includes an OPC client that can talk to the OPC server in the dedicated box.    B.  Alarm data that needs to be annunciated (something a PLC would do as an intermediary to the actual annunciator (light, horn, bell) If the dedicated box does analysis that can issue an alarm that means a failure is imminent and an alarm needs to be annunciated, then either Modbus or OPC could conceivably write a value to a PLC that the PLC (when so programmed) would interpret as an alarm for which it turns on an output connected to a horn/light/siren or even sends an email. C  something else? You select a server for server tasks and not a work station.  This is a similar situation - what is the data and what task has to be done with the data?  Previously I said, "the people who sell the high value data analysis software (your dedicated box) make it quite clear about what is needed as input for the software and what it needs to run with.   Now I have to ask a modified version, "the people who sell the high value data analysis software (your dedicated box) (should) make it quite clear about what data is available for export and what is available to export the data. At a minimum, you need to figure out what kind of data is coming out of the dedicated box and what needs to be done with that data - does it need a PLC or some other software?  To some extent you know there is OPC and Modbus, but you need more particulars: Does the dedicated box have - OPC DA server (older, more common version? - OPC UA server (more recent version)? - Modbus connectivity through Ethernet (Modbus/TCP)? - Modbus connectivity through RS-232 or RS-485 (Modbus RTU)? Is the device a Modbus client/master? or is the device a Modbus Server/slave? A server/slave (almost) always has a table or map of numbered registers that are used to call the data in that register.  Some very sophisticated server/slaves have a custom programmable table/map that the programmer populates with the needed data. Modbus is useful only for nearly realtime data points.  Although the Modbus specifications include some commands for block data transfer, almost no commercial devices implement those commands.   Those commands might be used by a proprietary software, but then you, the user, don't even need to know its Modbus, it's just the protocol used by the software. OPC has had some means of moving blocks of data, histories, but I have no direct experience in implementation of such, so I don't know how well it works or how wide spread those functions are.
  14. Analog sensors connect to the conversion device directly.  The conversion must have I/O capable of handling the analog signals. If the field sensors are not analog but use an industrial protocol (Modbus, Ethernet/IP, Profibus), then an OPC server could probably talk directly to the field device, but it is more common to get data into a PLC using the industrial protocol and then talk to the PLC through OPC. OPC or Modbus could be used between the conversion device and PC application software, assuming the application software has a access to an OPC client that can get data from an OPC server or a Modbus master/client.   Or an OPC server might be used to get data from the conversion device directly to a database, which the application software uses. OPC and Modbus are both bi-directional, so results of analysis can be sent back to a PLC for control/alarm action. 1.  There is no step-by-step procedure for a project of this complexity.   2.  With enough time and money, anything is possible.   The industrial world has done tasks like this (sensor data > PLC > analysis app) for decades now. 3.  This a question for the PLC/SCADA device vendor. A given PLC/SCADA device determines which communications protocols it handles (many times an option), which is brand/model specific.   If a PLC/SCADA handles a given comm protocol then its development software would have the means to deal with the comm setup and handling the comm data.   The interaction between application software and a PLC is almost certainly a custom programming job, which is what 'systems integrators' do for a living. 4.  Freeware I think most OPC servers will run for 2 hours in demo mode before they need to be reset, which is the development/test mode for the OPC server.  A run-time license would need to be purchased for the OPC server to run unattended.  But be aware, the purpose of an OPC server is to communicate the data to an OPC client, which needs to be associated with the application software.   One generally assumes any OPC server communicates to any OPC client, but there are freeware OPC test clients, also. There are freeware Modbus client/master and server/slave programs of limited functionality.  They are useful for testing but I'm not sure how valuable a Modbus test program is in the scope of this project. Direction PLCs make real time decisions on input data and change their outputs for control purposes - turn on a motor, generate an alarm, that kind of stuff.   What data analysis is needed beyond what a PLC does? Generally, the people who sell the high value data analyis software make it quite clear about what is needed as input for the software and what it needs to run with.   Isn't this clear for your analysis software?
  15. RS485 to Scale

    Congratulations.   Serial 485 is a pain, isn't it?   Delighted you got it running . . .