# Mettler Toledo IND560 **URL:** \ **Category:** General Discussion\ **Created:** [October 20, 2015, 4:02pm UTC](https://forum.inductiveautomation.com/t/mettler-toledo-ind560/10639 "2015-10-20T16:02:35Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Micky.Franks](https://avatars.discourse-cdn.com/v4/letter/m/c57346/32.png) [@Micky.Franks](https://forum.inductiveautomation.com/u/Micky.Franks)\ **Post date:** [October 20, 2015, 4:02pm UTC](https://forum.inductiveautomation.com/t/mettler-toledo-ind560/10639/1 "2015-10-20T16:02:35Z")
I am logging bag weights coming from a check weighter using the TCP driver. Works fine with the only exception that some bags going across it are not getting captured. I am pretty sure its from the bags going across too fast to get processed. As long as the bags stay within a bag every 5 seconds it’ll capture, any faster and they don’t get captured. I have the scanclass of the driver at 1 second and the transaction group logging the weights set at 1 second. I’ve tried the IA module for the IND560 but it doesn’t capture the “printed” weight. Anyway around this problem? ---
**Author:** ![cmisztur2](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmisztur2/32/4243_2.png) [@cmisztur2](https://forum.inductiveautomation.com/u/cmisztur2)\ **Post date:** [November 15, 2015, 7:43pm UTC](https://forum.inductiveautomation.com/t/mettler-toledo-ind560/10639/2 "2015-11-15T19:43:22Z")
We capture IND560 s through the UCON driver in Kepware. ---
**Author:** ![sartojunior](https://avatars.discourse-cdn.com/v4/letter/s/e68b1a/32.png) [@sartojunior](https://forum.inductiveautomation.com/u/sartojunior)\ **Post date:** [April 25, 2019, 5:54pm UTC](https://forum.inductiveautomation.com/t/mettler-toledo-ind560/10639/3 "2019-04-25T17:54:47Z")
Hi Chris! How are you? Can you share your capture using UCON driver in Kepware? Thanks! ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [April 25, 2019, 6:14pm UTC](https://forum.inductiveautomation.com/t/mettler-toledo-ind560/10639/4 "2019-04-25T18:14:11Z")
I’ve used direct socket connections (java networking in jython) to monitor an IND570 scale via its ethernet shared data server. You end up with weight status reports streamed from the unit multiple times per second. The IND560 appears to have the same ethernet capability. You want the unit’s “Shared Data Reference” manual to guide your coding effort. Found on the CD that comes with the unit. ---
**Author:** ![sartojunior](https://avatars.discourse-cdn.com/v4/letter/s/e68b1a/32.png) [@sartojunior](https://forum.inductiveautomation.com/u/sartojunior)\ **Post date:** [April 26, 2019, 5:46pm UTC](https://forum.inductiveautomation.com/t/mettler-toledo-ind560/10639/5 "2019-04-26T17:46:55Z")
We are using a opc server “kepserverex” with driver u-con to get the weight. We configured the module IND560 with especific layout and tcp/ip continuos output. On telnet is possible to get the weight. ---
**Author:** ![cmisztur2](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmisztur2/32/4243_2.png) [@cmisztur2](https://forum.inductiveautomation.com/u/cmisztur2)\ **Post date:** [April 30, 2019, 3:25am UTC](https://forum.inductiveautomation.com/t/mettler-toledo-ind560/10639/6 "2019-04-30T03:25:44Z")
You don’t want continuous mode (unless your process requires it), it constantly talks to the scale. I do not have the UCON driver handy, but basically what you are doing is issuing telnet commands and parsing responses, based on the scale’s manual (Technical Manual Appendix D). /c ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [April 30, 2019, 12:22pm UTC](https://forum.inductiveautomation.com/t/mettler-toledo-ind560/10639/7 "2019-04-30T12:22:28Z")
> [@cmisztur2](#): > > You don’t want continuous mode (unless your process requires it), it constantly talks to the scale. The OP says they aren't closing the loop fast enough with the query-response approach. Continuous output gives 10 or more updates per second, which should suit their application just fine. ---
**Author:** ![cmisztur2](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmisztur2/32/4243_2.png) [@cmisztur2](https://forum.inductiveautomation.com/u/cmisztur2)\ **Post date:** [May 1, 2019, 1:55am UTC](https://forum.inductiveautomation.com/t/mettler-toledo-ind560/10639/8 "2019-05-01T01:55:30Z")
Ah, yes I see. My request-response with demand polling through Kepware was sub-second, with thousands of daily transactions. I always had an issue with continuous output because which measurement do you accept without having a ‘stable’ bit and which weight is the next thing being measured? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [May 1, 2019, 1:09pm UTC](https://forum.inductiveautomation.com/t/mettler-toledo-ind560/10639/9 "2019-05-01T13:09:36Z")
Continuous output includes the stable status, among other things. For weigh-in-motion you basically have to use peaks between low-weight thresholds. Extra resolution on the time axis helps.