Created Date: December 12,2009

Created by: Steve Bailey

How often are you polling the slave? You could be asking for data more rapidly than it can respond. If so, and it creates a stack of pending requests, it may shut down when the stack gets full. Try asking for data less frequently to see if you get longer time between lockups.

Does the Procon unit have any diagnostic registers you could read to see if there are any clues?

Created Date: December 12,2009

Created by: icsbrad

Sorry, to quick with the post button. The unit has a Power LED, Bus LED (J1708), a MODRCV LED (request recieved) and a MODTX LED (modbus transmit). I can never see the MODRCV or MODTX LEDs blink unless I set the request rate up to about 2.5 sec, otherwise they are on steady. But, according to the mfg this is typical. The Power LED and Bus LED are on steady which is normal as well. Also, another thing I noticed was I never get a value in the Exception Response Buffer even when it is not working, curious huh? I have tried my own port 2 adaptor and also the A-D DN-15TB as its easier to see when it's not working by observing the LEDs, but in either case it fails within a couple of hours.

Created Date: December 12,2009

Created by: icsbrad

OK, here's another weird thing. Originally I was enabling 2 MRXs, one to read the first 30 of 61 registers and one to read the 2nd 30 of 61 registers (mfg says I should be able to read up to 32 consecutive registers at a time). I was then alternating back and forth between this 2 MRXs. Still problems. So, I decieded to simply the whole works and read only 1 register with 1 MRX, this is now polling once every 0.2 sec, twice the time the mfg says should be OK. Still problems. Now here's the weird thing, the Exception Response Buffer never does have a value in it, but when the thing stops working I can write a value in the same register as if the MRX is not ever being enabled, which I know it is by looking at the logic and and the lights blinking on the DN-15TB attached to port 2. Crazy!

Created Date: December 13,2009

Created by: milldrone

icsbrad,

Steve is doing a great job, but I'm wondering if you might clear up a few things for us?

You mentioned that if you reset the PROCON the comms resume. Have you tried stopping the PLC, switching to run, then switching to term? Or removing the power from the PLC and letting it reboot?

You mentioned the flashing lights on the DN-15TB. What you were not clear about was the frequency of the flashes. When the unit is communicating the flashing should be at the same rate as you are polling the slave. When the unit is not communicating the flashes should continue but at the base timeout X ? rate. Are the flashes continuing at the base timeout X? rate?

In your first post you mentioned that the port was setup for modbus. Did you uncheck all the other options?

Created Date: December 16,2009

Created by: icsbrad

Guys,

Thanks for the suggestions but the problem has been narrowed down. Yes, I did try to power cycle the PLC but the only thing that worked was to power cycle the PROCON, and yes when I lost comms the lights would flash at the timeout rate. Turns out it wasn't the Procon unit at all, it was the stupid simulator. This simulator was the first one out of the gate for the company (AU Electronics) using the J1708 protocol. It was some how screwing up the Procon unit so that it would not respond to the Modbus requests. To simplify the testing I was down to reading only 1 register every 5 seconds and it would lock up every 30 to 120 minutes. But, when it locked up I was starting to notice that the parameters that where being simulated were at the same value about half of the time. So...I disconnected the simulator and just let the PLC read non-changing values out of the Procon. It was fine for 4 hrs so I changed the logic back to reading 60 registers every 0.1 sec and let it continue for a couple of days and all is well. Thanks again for the help!

Created Date: January 05,2010

Created by: F.N.

Greeting icsbrad,

Thanks for using Au Group Electronics products.:)

I have just a short 4 ' cable connecting the PLC & the PROCON and am currentlly using 120 ohm termination resistors, although they shouldn't be needed.

Bus Termination shall not be used per SAE J1708 Section 4.4. The following picture illustrates a typical J1708 network topology: (120 ohm terminal resistor MUST NOT be used)

http://images.elektroda.net/29_1258132671.jpg

Violate the hardware network topology will lead to malfunction of nodes.

Here are a few more hardware and network topology requirement Per SAE J1708:

"About differential signal and wire:

*the two lines are switched between logic states.

*Bus Termination resistors as referenced in EIA RS-485 are not required and shall not be used.

*All assemblies using the link must have common ground reference.

*A minimum of 18-gauge twisted-pair wire, with a minimum of one twist per inch (360 degrees/2.54cm) is required. The twists shall be distributed evenly over the length of the wire.

*The bus supports a minimum of 20 standard nodes and the maximum total length of the network can be upto 131 feet (40m). "

Created Date: January 05,2010

Created by: MikeDuan

Hello icsbrad,

I have also tried a new PROCON unit but I am getting the same results. The only way I can get the thing to start working again is to reset the power on the PROCON unit. Resetting the power on just the PLC or the simulator attached to the PROCON does no good.

It seems to me a possible memory overflow/leak issue. The J1708/1587 uses 9.6K baud rate, it seems a low speed compare with many other protocols (e.g. 250K baud rate at J1939), however, there are still many data get repetition rate up to 100ms, such as percent engine load, engine speed etc. If the data wasn't handled fast enough, it will lead to receiver stack overflow, which eventually lead to loss of data. I am not familiar to PROCON, (a quick Google, lead it to a UK web), but is it possible that the receiver buffer overflow can lead to a malfunction unit?

Also, I forgot to mention the PLC is powered by a different power supply (24V) then the PROCON or the simulator (12V). I am now testing with the DC commons connected between the 2 supplies just in case.

Per SAE J1708 protocol, all J1708 nodes must use the same ground references:

"Ground: all assemblies using the link must have Common Ground References "

Please refer to the following link for more design practise on a J1708 network:

http://www.auelectronics.com/forum/index.php/topic,62.msg178.html#msg178

Created Date: January 05,2010

Created by: MikeDuan

This simulator was the first one out of the gate for the company (AU Electronics) using the J1708 protocol.

A new product doesn't means it is not fully tested. The Au J1708/J1587 simulator are designed strictly with SAE protocols. All releases are heavily tested before released to customers. We would be happy to help if there is any bug found or concern of using the device. All our J1939 and J1708 devices equipped with Au Group Electronics bootloader technology, which makes the device capable of upgrading the firmware in-field.

It was some how screwing up the Procon unit so that it would not respond to the Modbus requests.

This kind worries me. The purpose of using J1708/J1587 simulator is doing signal test before moving to the truck/RV/School Buses. From my personal understanding, our J1708/J1587 simulator is designed strictly with SAE protocols, if the Procon unit cannot withstand the relatively light traffic sending out from our J1708/J1587 simulator (the unit under you test only implemented about 7 PIDs, 6 transmitting PID, one request PID, on a real vehicle J1708/J1587 network, I am sure you will get more parameters), it will overflow/crash sooner in the real vehicle.

But, when it locked up I was starting to notice that the parameters that where being simulated were at the same value about half of the time.

This sounds interesting, have you read the parameters from the simulator remote terminal or from the J1708 bus? This is important to identify the root cause of the issue.

So...I disconnected the simulator and just let the PLC read non-changing values out of the Procon. It was fine for 4 hrs so I changed the logic back to reading 60 registers every 0.1 sec and let it continue for a couple of days and all is well.

It looks to me, after the device is locked up, it generate a constant dominate bit (under CAN protocol, it is called permanent dominant state, both CAN and J1708 uses differential bus, this can happen on both networks.), which will prohibit any other nodes talk over the network, would you please verify this with a oscilloscope?