Jump to content
OMRON Forums

MarkMF

Members
  • Posts

    2
  • Joined

  • Last visited

MarkMF's Achievements

Newbie

Newbie (1/14)

  • First Post
  • Conversation Starter
  • Week One Done
  • One Month Later
  • One Year In

Recent Badges

0

Reputation

  1. I have run into a small problem using the Library. I am attempting to make a DLL using the MinGW compiler in C++ without .NET. I am basing this on the BCB5 example as it seems the most applicable to me (C++, no .NET). I am creating the handle to IPmacDevice this way: IPmacDevice *g_idevice = NULL; HRESULT result; result = CoCreateInstance(CLSID_PmacDevice, NULL, CLSCTX_LOCAL_SERVER, IID_IPmacDevice, (void **)&g_idevice); if(SUCCEEDED(result)) { g_idevice->AddRef(); } I then open the device. short itemp; VARIANT_BOOL success; long d = 0; g_idevice->Open(d, &success); Device 0 has already been setup using PEWINPRO2 so I do not need SelectDevice at this time. At this point this function succeeds and returns VARIANT_TRUE. The trouble comes when I run this function: wchar_t *answer = new wchar_t[256]; wchar_t *question = new wchar_t[256]; long d = 0; long g_lasterror; swprintf(question,L"TYPE"); g_idevice->GetResponseEx(d,question,VARIANT_FALSE,&answer,&g_lasterror); It is here that I get a crash and an "Unknown signal" message from my debugger. Have I missed anything in using the library at this point?
  2. I have a legacy application that used the old PCOMM32.dll library. According to the PCOMMServer Pro 2 documentation, PCOMM32W is "A wrapper for the IPmacDevice Interface for legacy programs." So I am guessing what I am doing is exactly what PCOMM32W was meant for. I should note that the legacy application has been used for years successfully before the upgrade to the new Pcommserver Pro 2 Library. I have been able to successfully link to the PCOMM32W.dll library with the existing code, but I have noticed some discrepancies. OpenPmacDevice(gDeviceId) Under PCOMM32.dll this returned 0 for false and 1 for true. Under PCOMM32W.dll this returns 0 for false and 0xFFFF for true. I can work around this one easy enough, and after opening the device I can use the PmacGetResponseExA successfully. PmacDPRGetMem(gDeviceId, gPmacFromOffset4, gNFromPmac4,gFromPmac.f) Under PCOMM32.dll this would successfully fill gFromPmac.f with data from the DPR. With PCOMM32W.dll this fails to fill gFromPmac.f with any data at all. Are there any appnotes on PCOMM32W.dll covering problems such as this? Is there a change in the behavior of DPRGetMem? Any help on this would be appreciated.
×
×
  • Create New...