FBL2360 encoders no more read

Hello,

I'm gonna give you a chronological order of the facts:
I had an FBL2360 which I substituted for another FBL2360 because the old ground pins of the driver's I/O were burned; reading more deeply the manual we realized that we mistakenly created a path from the battery minus and the I/O: briefly, the aluminum chassis acted like a big ground pin which connected the battery minus, passing trough all the gearing, directly to the encoders and to the I O ground. Suddenly a short-circuit burned those pins during a maintenance day. We solved the problem buying a new Driver and insulating both the driver and the encoders from the aluminum chassis, and testing it with a multimeter we can definitely say that, now, there are no more path leading to the battery except the normal wiring.

Little flashback: before creating the aluminum chassis everything worked perfectly, we have 2 brushless DC 24v motors, with incremental encoders plugged on. And, also if we have had the issue of the "ground path" the LGV worked for more than 1 month. We realized that something was wrong because encoders were no more read, so they gave 0 output speed also while moving, translating in a constant thrust to each motor, which accelerated more and more even with a 1% velocity command.

Now that I've the new controller and that we insulated the I O from the ground I re-plugged everything with the same working configuration of the lasts FBL2360 but the encoders are still not read. So I tested all the I O ports and, as the controller is new, are perfectly working. Then I decided to test the encoders, expecting that they were burned too: reading with a oscilloscope you can clearly see that the encoders are both counting.
So that's the fact, I can't figure out how to solve this situation.
Using the roborun utility no data seems to arrive from the encoders, except one of them which provides a speed of an oscillating 0-1, which is pretty strange.
Does anybody had the same issue? I really can't figure out the problem, maybe the encoders are burned even if you can see the impulse train with the oscilloscope? Maybe are just a little burned but enough to read with oscilloscope the variation but not to read with the controller? Maybe the controller has different Enc default pinout?
Please help and thank you for your time!

Actually from the Roborun Utility, switching to open loop both the channels just to test the encoder reading, we can read 0 count for the enc1 and an oscillating value for the enc2 count and speed (oscillation from -1 to 1). Is it possible that the encoders output is just too low to cause the oscillation for the enc2 and the 0 for the enc1?
Each kind of support is very much appreciated