Oh, if they are out of business it will be more tricky, but I might still be able to dig up some more info. What was the name of the company who manufactured and sold the machine?
Ok, then there would be three J1939 modules. All would have the property PGN set to 0, and the destination address set to 0, 1 and 15 respectively.
Because of the check for "multple TSC1" you would need to have them assigned to three separate J1939 modules, one for each destination address.
For the SPN channels that are active, but where you do not get a popup message, what is the dialog property set at? The default is "don't show", so that could be the reason.
The picture is of an IQAN-DG, this is the display on the first generation of IQAN systems. The IQAN-DG display is a slave display, the machine control application for this is loaded in the IQAN-MG module (the large module with two 42-pin connectors, one at each side). Probably that is where the RS232 cable is connected.
The service tool for this system is called IQANtalk.
The tricky thing about this system is that all applications were custom made, and the IQANtalk service tool is locked to specific OEM:s with a "Manufacturer ID". Therefore, to get the correct key for IQANtalk, it will have to be aquired through the OEM who manufactured the machine.
It could also be tricky to get IQANtalk to work on a modern PC. It has been a while since I used it myself, but I know some guys keep their old Windows XP computers to use for these systems.
There is a limit of one TSC1 channel that exists also in IQANdesign 3. But in version 3, the check for this is not discovered, because the "PGN" property is set to 1. In version 3, this was the only way one could get the DA information for a PDU1 message into the identifier.
In version 4, the PGN property is used in the same way as the standard (TSC1 is always PGN 0), and there is a separate property for Destination Address, DA.
What you do in version 4 is that you have one J1939 module for each node address that you are communicating with. Set the DA property to "assigned module", and place one TSC1/JFOUT channel per module.
In your application, I am guessing this is only one engine, right? It is very interesting to hear that you used two separate destination addresses to send TSC1 to it.
Looking at some older application files, I have instead used separate IQAN source addresses to send a combination of speed command and torque limitation from IQAN to an engine.
About the property "frequency/direction" on the DPCNT, this is for using an older type of directional sensors, where one signal is used for frequncy, and an on-off signal is used for direction. It is actually only the XA2 expansion that has support for this kind of sensor.
On all other IQAN modules with DPCNT, the channel expects a pair of phase-shifted signals.
The DPCNT input on the MD4 is designed to be used as an input for rotary encoders, for example to control the meny system without using the touch. The hardware on the MD4 that counts the pulses is limited to signals of max 500 Hz frequency (assuming MR is 50%), that is why we did not make the same pins configurable as FIN or DFIN.
It would have been nice with a proper frequncy input on the MD4, but the hardware does not support it. The most cost effective way to add FIN to your system would be to add an XC21 or XC22
If you look at the channel when it show the red status, the tool tip help is most probably indicating "timeout" or "no contact".
We have found an issue in 4.00 that JPIN (and GPIN) channels of value type real do not recover from timeouts when the message is recieved again. JPIN/GPIN of value type integer or boolean is implemented differently, and here this bug does not exist, that is why your workaround solves it.
The bug is fixed in version 4.01, release date is middle of February.
I think it is a good idea, a very similar idea is posted here:
Customer support service by UserEcho