VFD Display by NEC: FC20X2JA-AA

[anymohr]

oops, sorry. here is the corresponding config.log. I´m learning...

The the display can also be addresses from the parallel port. I think WR and so on are needed when connecting in a parallel fassion. I only attached plus 5V, GND and the RX of the display to the Tx of the PC. Maybe I am wrong but the terminal programs work fine with the display as well as the software from that page:
Ansteuerung von Vacuum Floureszenz Displays mit dem PC (Dos und Winamp) (only german though).

[cybrmage]

hmm... that's the page I found as well....

did the last set of changes have any effect??

If it works with the program on that page, you probably have the display wired correctly... it just isn't using the raw FC20X2JA command set...

Try these command parameters...

Display Init: x1B x5B x32 x4A
Cusor Home: x1B x5B x30 x3B x30 x48
Cursor Down: x0A
Clear Display: x1B x5B x32 x4A

and let me know if the driver does anything different... If it does, I'll have to make some changes to the driver to accomodate the command set...

[anymohr]

sorry cybermage, no change in the behaviour at all when trying out your latest suggestions.
later I tried the plugin of today, the difference I found was that config crashes after repeatedly pressing "test display". sometimes after 3x sometimes later (12x). Also it would only really try to test the display once. After the first time it behaves as it does on my COM1: the button comes back after some milliseconds.

I did some investigation using a terminal program that would also display hex control data. this is how your init string came out of configguration.exe: "\01\11\14\0CCybrDisplay GenericSerial \0C".

I then used the program from the link I sent it it behaves pretty much the same: "\01\02\03\04" for fading, "12345" for sending "12345", etc. The only thing that was curious was that hitting the CLS button did not show a "\0c" in the terminal program but something that looked like a CRLF: it jumped to the beginning of the next line.
I then tried adding x0a and x0d in various combinations and each alone. No difference again.

I think your explantion that the character come too quickly makes currently the most sense. But: why is the last character (the one after those 5s, you send 0x0c) never the same on my display? One single character can´t be too quick can it?

[cybrmage]

Originally Posted by anymohr

sorry cybermage, no change in the behaviour at all when trying out your latest suggestions.

Did you try the latest driver... The log you posted inficated the first of todays drivers... There have been timing fixes in the subsequent drivers

Originally Posted by anymohr

I found was that config crashes after repeatedly pressing "test display". sometimes after 3x sometimes later (12x).

Originally Posted by anymohr

One single character can´t be too quick can it?

I would think that a single character couldn't be sent too fast.... It could be that the particular revision of your device doesn't support that command (The datasheet that lists the commands is from 1991, and you did mention that the device is labeled 1989)

[anymohr]

I just tried the latest driver you posted early morning my time. Still garbage on the display and still crashing after some pushes on "test display".

Concerning the garbage I think you are right. The only explanation that makes sense is that the characters come too quickly and confuse the input buffer of the controller. That would also explain why even one last character is screwed up.

You don´t happen to be in Germany or in Europe anytime soon? I would give you one of my displays.

[cybrmage]

Originally Posted by anymohr

I just tried the latest driver you posted early morning my time. Still garbage on the display and still crashing after some pushes on "test display".

As I said... I can't duplicate this... (I sat here clicking on the "test display" button for 20 minutes!!!)... Please post the configuration.log from when it crashed so I can try to fix this issue...

Originally Posted by anymohr

Concerning the garbage I think you are right. The only explanation that makes sense is that the characters come too quickly and confuse the input buffer of the controller. That would also explain why even one last character is screwed up.

I agree.... What have you put in for the "comm. delay" setting (In the plugin configuration, not the "advanced configuration"). According to the datasheet, it can need up to 100ms... (yes, this setting is in milliseconds)... also, try higher values, just to see if it makes a difference...

Originally Posted by anymohr

You don´t happen to be in Germany or in Europe anytime soon? I would give you one of my displays.

I appreciate the sentiment.... 8-}

I don't travel that much... except within western Canada.... The last time I was in Europe was 38 years ago... 8-}

[anymohr]

Attached is the configuration.log using "CybrDisplayPlugin_03_23_2008b" of today. I used COM2 (that resides on a PCI card) and the driver crashed after about 5 pushes. And so it does when I use COM3 that is also on the PCI card. The driver will still test the display only once after starting MPconfig (not only the driver plugin setup).

When I am using COM1 (legacy on mainboard) the driver does not crash but it won´t write anything to the display either. (configurationCOM1.log)

In both cases the assert RTS and DTR settings are not sticking. Exiting advanced config and reentering > those settings are gone.

For comm.delay I put in 10ms, 100ms, 200ms. The result is always garbage on the display only at different speeds.

[anymohr]

Ahm, I don´t really know how to say this...
the garbage is gone and the messages are displayed nicely on the screen. From the behaviour of soft- and hardware I decided that the problem must have to do with my hardware and I changed the levelshifter I was using for the display and that solved the issue with garbage beeing displayed. I don´t know why that very levelshifter (MAX3232CPE) works fine with the terminal emulators and the VFD control program off the web but fails with your plugin. Maybe it has to do with the way they are wired. I do not have the schematics. I can even send at 0ms comm.delay. I hope you can forgive me for waisting your time.

The issue with the plugin crashing on COM2 and 3 and not talking to COM1 is still there when using that other shifter (also a 3232 from some other manufacturer, can´t read which).

Also RTS and DTR still will not stick. Being able to use those signals would be very usefull for me as I plan to replace the cable between Display and PC by a class1 bluetooth connection and my bluetooth device needs those signals asserted to autoconnect.

Do you want me to keep testing the issues above?

I you gave me your address I would send out one of my VFDs to you. And could you also use a T6963C based LCD? I have some of those as well.

[cybrmage]

Originally Posted by anymohr

the garbage is gone and the messages are displayed nicely on the screen.

That's good!!!

Flaky hardware is always a pain to deal with, and can malfunction in a number of ways... I suspect that the difference is that the MediaPortal plugin pumps data to the display almost constantly... whereas the Terminal and the other program sends data intermittantly...

Originally Posted by anymohr

I hope you can forgive me for waisting your time.

Don't worry about it... It allowed the driver to develop...

Originally Posted by anymohr

Also RTS and DTR still will not stick. Being able to use those signals would be very usefull for me as I plan to replace the cable between Display and PC by a class1 bluetooth connection and my bluetooth device needs those signals asserted to autoconnect.

Sorry... I haven't had a chance to look at this issue yet... I've been working on one of the other drivers... I will resolve this issue for the next version.

Originally Posted by anymohr

Do you want me to keep testing the issues above?

If you are still having issues with the plugin when using the operational hardware, then yes... please continue with the testing so that the bugs can be fixed.

Do you have issues with the ports when using the operational hardware??

Originally Posted by anymohr

I you gave me your address I would send out one of my VFDs to you. And could you also use a T6963C based LCD? I have some of those as well.

While I appreciate the offer, it is not necessary... besides, shipping from Germany to Canada would cost you a small fortune 8-}


EDIT: I think I found the problem with the "test display" button no longer functioning after being used several times. For the issue with COM1, the logs did not reveal anything usefull... so I have added some extra debugging to try and catch it...

[anymohr]

I will finalize my hardware (bluetooth connection and and so on) and then get back to you after having tested the latest driver. So far I would like to thank you so much for your help!