Is there any way to get a MX2 series LCD without paying the registration fee for LCDC?
Two reasons I want this. One, the LCD is for an embedded application where I will be driving the LCD myself through my own code, therefore the extra 'hidden' cost of the LCDC registration built into the price of the MX2 LCDs is something I don't want to pay. Basically, an MX2 costs $99. LCDC costs $17.50. If I don't want or plan to use LCDC, I should only have to pay $81.50 for the LCD itself.
The second reason is that LCDC is artifically crippled to only work with Matrix Orbital LCDs. If I AM going to pay for it, I expect to be able to make the program do anything it physically can do, including allowing me to make my own definition files to work with other LCDs that I may acquire in the future. Therefore, I would not register the program, and instead choose to write my own software to talk to it from the ground up, as I am already doing for the embedded application.
Translation, I really, really, really want the USB interface to the LCD, but I really, really, really do not want to pay for or use LCDC.
MX2 series WITHOUT LCDC?
Of course it is. MO gives a driver that creates a virtual COM port, then
just take the old USB manual and send the commands directly.
Even if that driver is somehow part of LCDC, which I doubt, it's still not
THAT hard to write your own device driver, a task I'm already considering
for other reasons.
just take the old USB manual and send the commands directly.
Even if that driver is somehow part of LCDC, which I doubt, it's still not
THAT hard to write your own device driver, a task I'm already considering
for other reasons.
Ahh, I see. Well, that's rather what I'm asking them. It seems they have great flexibility in their older product lines, but in the MX2, it's very restrictive.
Such as:
Must buy LCDC
Must buy case mount bezel
Must buy with their filter
Must be character oriented (fine for me actually, here, that's what I need)
Such as:
Must buy LCDC
Must buy case mount bezel
Must buy with their filter
Must be character oriented (fine for me actually, here, that's what I need)
Just buy a LK202-USB http://www.matrixorbital.com/pages/prod ... oductID=93 same thing (And a panel if you want item B202A
), secondly MO do NOT pay that amount for LCDC they get it at a seriously discounted price. PS I have to admit I find it quite amusing at the lengths you are going to to avoid LCDC just because I made a decision to run exclusivly with MO!
), secondly MO do NOT pay that amount for LCDC they get it at a seriously discounted price. PS I have to admit I find it quite amusing at the lengths you are going to to avoid LCDC just because I made a decision to run exclusivly with MO!
## # Mat # ##
LCDC - Drive it to the edge baby!
http://www.lcdc.cc
Matthew@DPS.uk.com
DPS Ltd. (Not MO!)
LCDC - Drive it to the edge baby!
http://www.lcdc.cc
Matthew@DPS.uk.com
DPS Ltd. (Not MO!)
Re: MX2 series WITHOUT LCDC?
As Mat said, we do have a bulk discount so you really can't just subtract $17.50 from the price. The MX2 is a kit, you get a discount for buying all the pieces of the kit together.flipper wrote:Is there any way to get a MX2 series LCD without paying the registration fee for LCDC?
Two reasons I want this. One, the LCD is for an embedded application where I will be driving the LCD myself through my own code, therefore the extra 'hidden' cost of the LCDC registration built into the price of the MX2 LCDs is something I don't want to pay. Basically, an MX2 costs $99. LCDC costs $17.50. If I don't want or plan to use LCDC, I should only have to pay $81.50 for the LCD itself.
This is like complaining that Windows will not work on an iMAC or OS X will not work on a x86 system. The reason why LCDC is the best program in the world for LCD's/VFD's is because how closely Mat and I work together.The second reason is that LCDC is artifically crippled to only work with Matrix Orbital LCDs. If I AM going to pay for it, I expect to be able to make the program do anything it physically can do, including allowing me to make my own definition files to work with other LCDs that I may acquire in the future.
As Mat said again, you can purchase the LK202-24-USB, then you can get a USB cable, internal or standard A to B and the bay insert. The price is going to be very close to just purchasing a MX2 display though (and you will get a newer LK202-24-USB, rev 1.4 in the MX2 kit)Translation, I really, really, really want the USB interface to the LCD, but I really, really, really do not want to pay for or use LCDC.
Henry J.
President
Matrix Orbital
President
Matrix Orbital
Hmm, okay....
First people seem to be confused as to why I wouldn't want LCDC. Let me explain what I'm going to be doing with this, as maybe I'm missing the boat. Application is a PC squirrelled away in a back room, outputing a video source to a set of TV's. About 5 people will have access to the back room, so the LCD will not do anything except (if all goes well), display "Video Output Good" for 5 days. If something goes wrong with my software, the LCD is going to be the only way to get useful output from the software, as the VGA port is busy trying to display stuff to the TVs. Therefore, there will be no monitor available to view the desktop to configure LCDC, and displaying "Video Output Good" is real overkill for it's, admittedly impressive, capabilities. Therefore, having my program control it is by far the easiest way.
The idea to set it aside is nice, but look at it this way. Reality is, it's going to do exactly what I want, people are going to say "Cool!", go home, and it's all going to go back in the box to be forgotten. However, in my little pipedream world, maybe I could sell 10 or so copies. Each with a custom built PC, with a LCD display. Now I have 10 copies in my house, none of which I want, none of which are any good to me.
Thus, mostly, it's a priciple of economics. I'm paying for large amounts of stuff I can't use. I never like doing that.
However, there's an alternative. LCDC is much like a driver, sitting between my app and the LCD, polling information as it needs to. Could be extremely useful. Lets say that I go into 'production' (pipe dream, I know), and I find a discount on LCDs from somewhere else. If LCDC allowed me to edit the configuration files (that it already posesses, and that already support NON-MO LCDs), then as I needed to shift from one mfr to another based on supply and price, then it would give me great flexibility, and I'd happily learn to use it. Even tho I'd have to buy and learn Delphi to write my customized plugins to allow the box to be configured and controlled through the LCD.
But, the files are digitally signed, creating an artificial barrier to me doing this. Therefore, the added weight of the midlayer, trying to control LCDC by banging directly on it's config files since the desktop will not be visible at any time during operation, the cost of Delphi to write my own plugins....it's just not worth it.
What annoys me about LCDC is not that it ONLY supports MO displays. Even my own app is likely to ONLY support one mfr's displays. It's the fact that it USED to support other mfr's, could support any mfr in the world through it's config files, and the support is deliberately crippled out. Given the Mac/PC comparison, it would be like a software author altering their software to detect VirtualPC and saying "Cannot run on VirtualPC" for no better reason than they didn't like it. With the power available in the definition files, I could support any LCD I wanted by changing just a few characters, and the digital signatures arbitrarily prevent it.
I'm not saying that LCDC should go out of it's way to SUPPORT other mfr's LCDs, but it shouldn't go out of it's way to PREVENT me from modifying it to do what I need. Even with my own app, if someone can get it to run under VirtualPC (which I doubt they could, due to the heavy use of DirectX), more power to them. They just get both pieces when it breaks. If I support MO LCDs, and someone wants to go in and modify my executable to support someone else's LCDs, I promise and swear there will be no code to stop them. There is code to stop that sort of thing in LCDC, hence my problem with it.
First people seem to be confused as to why I wouldn't want LCDC. Let me explain what I'm going to be doing with this, as maybe I'm missing the boat. Application is a PC squirrelled away in a back room, outputing a video source to a set of TV's. About 5 people will have access to the back room, so the LCD will not do anything except (if all goes well), display "Video Output Good" for 5 days. If something goes wrong with my software, the LCD is going to be the only way to get useful output from the software, as the VGA port is busy trying to display stuff to the TVs. Therefore, there will be no monitor available to view the desktop to configure LCDC, and displaying "Video Output Good" is real overkill for it's, admittedly impressive, capabilities. Therefore, having my program control it is by far the easiest way.
The idea to set it aside is nice, but look at it this way. Reality is, it's going to do exactly what I want, people are going to say "Cool!", go home, and it's all going to go back in the box to be forgotten. However, in my little pipedream world, maybe I could sell 10 or so copies. Each with a custom built PC, with a LCD display. Now I have 10 copies in my house, none of which I want, none of which are any good to me.
Thus, mostly, it's a priciple of economics. I'm paying for large amounts of stuff I can't use. I never like doing that.
However, there's an alternative. LCDC is much like a driver, sitting between my app and the LCD, polling information as it needs to. Could be extremely useful. Lets say that I go into 'production' (pipe dream, I know), and I find a discount on LCDs from somewhere else. If LCDC allowed me to edit the configuration files (that it already posesses, and that already support NON-MO LCDs), then as I needed to shift from one mfr to another based on supply and price, then it would give me great flexibility, and I'd happily learn to use it. Even tho I'd have to buy and learn Delphi to write my customized plugins to allow the box to be configured and controlled through the LCD.
But, the files are digitally signed, creating an artificial barrier to me doing this. Therefore, the added weight of the midlayer, trying to control LCDC by banging directly on it's config files since the desktop will not be visible at any time during operation, the cost of Delphi to write my own plugins....it's just not worth it.
What annoys me about LCDC is not that it ONLY supports MO displays. Even my own app is likely to ONLY support one mfr's displays. It's the fact that it USED to support other mfr's, could support any mfr in the world through it's config files, and the support is deliberately crippled out. Given the Mac/PC comparison, it would be like a software author altering their software to detect VirtualPC and saying "Cannot run on VirtualPC" for no better reason than they didn't like it. With the power available in the definition files, I could support any LCD I wanted by changing just a few characters, and the digital signatures arbitrarily prevent it.
I'm not saying that LCDC should go out of it's way to SUPPORT other mfr's LCDs, but it shouldn't go out of it's way to PREVENT me from modifying it to do what I need. Even with my own app, if someone can get it to run under VirtualPC (which I doubt they could, due to the heavy use of DirectX), more power to them. They just get both pieces when it breaks. If I support MO LCDs, and someone wants to go in and modify my executable to support someone else's LCDs, I promise and swear there will be no code to stop them. There is code to stop that sort of thing in LCDC, hence my problem with it.
Just to make clear my big concern about LCDC. It's good ONLY with MO LCDs. That locks me to MO LCDs.
Thus, I cannot respond to changes in pricing that occur, and means that I'd have to buy potentially the more expensive product just because I was using a MO specific piece of software.
If I do it myself, I already have a retargetable midlayer that I wrote for a completely different LCD, and I can retarget it to MO, LIS, Seetech, whoever is best right at the moment.
I just don't like the concept of buying a piece of software that I plan on throwing away without ever even installing it. I might be able to use the one copy I'd get with the prototype.
Not that using the one-wire interface isn't tantalizing, thus I may go with an MX2 anyway, just doens't make economic sense for the future. If only it were documented on accessing it.
Manual doesn't seem to discuss the one-wire interface.
Thus, I cannot respond to changes in pricing that occur, and means that I'd have to buy potentially the more expensive product just because I was using a MO specific piece of software.
If I do it myself, I already have a retargetable midlayer that I wrote for a completely different LCD, and I can retarget it to MO, LIS, Seetech, whoever is best right at the moment.
I just don't like the concept of buying a piece of software that I plan on throwing away without ever even installing it. I might be able to use the one copy I'd get with the prototype.
Not that using the one-wire interface isn't tantalizing, thus I may go with an MX2 anyway, just doens't make economic sense for the future. If only it were documented on accessing it.
Manual doesn't seem to discuss the one-wire interface.