Jump to content

Simon

MVP 2014
  • Posts

    598
  • Joined

  • Last visited

  • Days Won

    34

Posts posted by Simon

  1. Joe, when the relays wear out, can I replace them with replacement relays from Unitronics? Or do I have to replace the whole printed circuit board, or worse, the whole V130 PLC?

    I'm not Joe, but usually the official line is that you would need to send the entire PLC back to Unitronics for repair.

    However, Unitronics usually list the manufacturer's part number(s) of the relays in the PLC datasheets, and they aren't too hard to find in stock at general electronics suppliers.

  2. I suspect no-one uses the ML for ASCII, except for newbies. Visilogic allows you to do it, so yes it should work, but in my experience there seem to be some problems. These probably haven't been found becuase the ML are not frequently used for ASCII.

    Why? I suppose it seems more efficient, as half the number of ML compared to MI are required to store a string. Also, the MI are generally used for standard programming tasks, so putting the ASCII in ML values keeps the MI area free for other use. This is somewhat a moot point as even the V120 offer 2048 MI values, but to each their own.

    If I have the opportunity I will make up a basic example for support to take a look at. If I uncover any of my own mistakes I will be sure to post an update.

  3. Does any one have comments good or bad about using ML values to store ASCII strings?

    I have been debugging an application where the FB Protocol was used (serial), on a V350.

    It is Visilogic 9.0.1 with the latest publically released OS

    The app has a CopyBuffer block, copying to ML values, with 4 bytes per linked operand. The vector of MLs is then linked to an HMI display.

    However when data is received on the serial port, nothing is stored into the vector of MLs, or displayed on the screen. When I manually type some ASCII codes into the ML values, the characters appear on the linked HMI element, so at least that part is working.

    With exacly the same logic, I changed the ML to MI and it all works fine.

    So, has anyone else had a problem, and has anyone else got it working?

  4. Using a shielded cable may work, by keeping the noise out.

    Also try to reduce the amount of noise

    * make sure the solenoids have RC snubber networks on the coils, to reduce switching transients

    * use solid state relays rather than mechanical relays. The latter provide some magnetic coupling between the coil circuit and contact circuit, allowing the nasties to conduct back into the PLC.

    * check that all grounds and commons are connected in a star formation, with no loops to allow noise currents to circulate.

  5. I am using a Jazz JZ-10-11-UA24 to control a relatively simple ETS furnace. I am using a PT100 for sensing the outdoor air temperature (typically -15 to 100 F) and a type K thermocouple to measure the storage core temperature (Typically 70-1200 F). I have 2 instances of this application in operation with great results with 1 exception. The variables are not as stable as I would like. The PV's change slowly so a heavy filter would be acceptable. I am experienced with the Vision series and have been spoiled by the great selection of FB's. Can someone please help me with an example of code to filter an MI using tools that are available in M90 Ladder?

    Hello Sparky,

    Please see attached.

    Filter with Shift Reg.U90

  6. There are a few of options I have used.

    1. Check the features of the Vaisala instrument - maybe you can change the numeric format to have "leading zeroes". That will make the numeric fields always have a constant length.

    2. Determine the number of different possible messages based on the different length numeric variables that can be sent. If there are not "too many" different messages then create a protocol scan message for each different option. When the input message is received the PLC will match it to the scan message that fits.

    3. If there are too many variations to use option 2, then the only other option is to use the "stream" variable type to catch the string as a stream and decode it using ladder programming. This is by far the more complex option, so I would look very closely at whether you can solve it with option 2 above.

  7. Hello Marko,

    Quick question: are you using 115,200 baud? This is required, as the enhanced series PLCs always revert to 115,200 baud once the OS has been erased.

    Also, try powering down the unit, removing the battery and leaving the unit powered down for at least 30 minutes. Then power up with your finger on the (i) key, and try the OS update again. Once all is well you can put the battery back in.

    DISCLAIMER: I haven't yet powered up a V560 for myself, so am assuming it behaves the same as its cousins.

    • Like 1
  8. I have now given the Beta a run, and also like the higher colour depth. Will this flow on to the colour selection for HMI objects like buttons? I note that the choice is still only 9 colours for 3D buttons and 256 colours for flat objects. Rather than a colour picker with 65536 colours, just the ability to enter the RGB code would be fine...

    Also, since this update brings 16-bit colour to the V350 and V570, are we any closer to seeing an active USB port on the V570?

    (I tried it out after loading the Beta OS and it came up in the Windows Device Manager as an Unknonw Device called Test2, but went no further.)

  9. I addition to the signal strength there is also a BER (Bit Error Rate) that the modem returns when queried for signal strength. If the signal is good, but there is a high BER, then it will also fail to initialise on the network. I have seen this cause some problems initialising modems on the bench. I'm not 100% sure what would cause a bad BER with good signal, but electrical interference could be one thing.

    Going down the track of whether the provider is a factor, are the problems occurring in one geographical area or spread around?

  10. Hi Ash,

    We don't hear much about Ethercat. Knowing a bit about it's evolution from the Beckhoff origins, it seems to be best suited to very high performance applications, like machine tools and other motion control applications. I wouldn't push for it from my point of view.

  11. For me it comes down to the simplicity and elegance of the Unitronics units. Why do users still get excited about a 3.5" colour touch a-la the V350? Maybe becuase it fills their needs in a simple and unique way. IMHO, a screen size above about 12" starts to get away from this fundamental elegance. I would rather see enhancements to the existing range, such as wider range power supplies (10...30V), wider temperature ranges (upper limit of 60 or 65 degrees C) and industrial ethernet protocols such as Profinet and Ethernet/IP.

    There are plenty of Modbus HMIs available if big is really required. However, if Unitronics came up with a 19" touch with an elegant look and feel then I am sure it would be a winner. :(

  12. There are port sharing devices available, but they rely on appending a code to each packet to tell the device what serial port to send it out on. This isn't useful for Modbus, unless you want to manually code the modbus packets with the protocol send blocks.

    As per Bill's post above, I am a little unsure why you need electrically separate networks, rather than separating the pumps using their modbus IDs. Maybe if the unused pumps are powered down do they kill the RS485 comms?

    Next option, maybe a DPDT relay controlled via one of the PLC outputs?

×
×
  • Create New...