Local RS232 via RTC

iRon

Hi ya'll and a Happy New Year!

I'm relatively new to NAV. So far mibuso.com has been a great help in many of my NAV related questions/problems the last months. Thank you very much for this great place :thumbsup: .

I'm stuck with a problem trying to make the RTC communicate with the local COM-Port. My stuff works just great on CC, but on RTC-mode the service tier ruins my day #-o . Is there any way I can sort of outflank the service tier - in order to communicate directly with the the local serial port/device?

Would be grateful for any advice or suggestions.

Ron

MarkHamblin

If this is to integrate with a cash drawer or something similar, check out the Microsoft POS SDK. If you want to send/receive, you could either create your own COM/.Net object to do it, or use one of the commercial/free ones out there.

ara3n

what COM object are you using? Did you instantiate it on the client?

iRon

MarkHamblin wrote:

If this is to integrate with a cash drawer or something similar, check out the Microsoft POS SDK. If you want to send/receive, you could either create your own COM/.Net object to do it, or use one of the commercial/free ones out there.

It's for a scale connection on the client side. Right now I'm using a tyre tread depth gauge for test pruposes. Shouldn't make that much of a difference. Just want to get the com data directly from the client's com port and not that of the server, which is the case when connected to the service tier.

ara3n wrote:

what COM object are you using? Did you instantiate it on the client?

Yes, the COM object is instantiated. But when implemented in a page it references the com port of the server where the service tier runs and not the com port of the client. It works well on a classic client since the it references the com port of the client to which the device is connected.

I'm using mscomm32.ocx, btw. Is there any way to make a page act like a form in certain scenarios? Like when connecting hand scanners or scales to a Role Tailored Client? To me, it looks like Microsoft didn't think of these pretty common scenarios when designing the RTC :-k

Thanks,
Ron

ara3n

how are you instantiating the com. can you paste your code?

BardurKnudsen

Just a suggestion: You can access the serial ports from .net - read more here: http://msdn.microsoft.com/en-us/library ... lport.aspx. You can instantiate .net objects on the client side (property on the variable).

iRon

Thanks, but I can't post any code until next week since I'm on vacation . However, it's intantiated just like you would in classic client - which works just fine. As I've said, the problem is definitely the nature of the RTC, which only communicates with the server ports, thanks to the service tier. But generally, looks like Microsoft didn't think this through the end or there would be a NAV option for this. Or maybe it's just me being spoiled in Java

I'm most probably gonna have to provide a .NET solution for the issue.

ara3n

They have added a new parameter on the function CREATE so that you can decide where to instantiate the COM object.

iRon

Hi,

back at work with good news. Thanks Rashed!

ara3n wrote:

They have added a new parameter on the function CREATE so that you can decide where to instantiate the COM object.

Just for those interested, the CREATE Function(Automation) does now offer the following parameter:
[Ok :=] CREATE(Automation [,NewServer] [,OnClient])

The following instantiation solved my problem:
CREATE(Automation, FALSE, TRUE) //wherein TRUE stands for create obj. on client.

Cheers! =D>
Ron

ara3n

3 of my posts were on the fact that you were not instantiating it correctly and lo and behold that was the problem.