DIY XMC-1 PC App.

[wilburthegoose]

Nope - Still running 3.1

[Chuck Elliot]

3.1 or 3.1a should make no difference.

Your system is acting like its the wrong version of the PC App. Parse Error 139 was fixed a long time ago.

I would remove the program using the control panel and then reinstall "XMC-1 PC Remote Version 3.1.0" from the first post in this thread.

If this fails could you detail your actions starting with invoking the program until you get the error.

I dive in tomorrow night - I'll get it fixed if there is an issue!

[wilburthegoose]

Bingo. I downloaded an older version.

Thanks again for a VERY important part of my Home Theater!!!!

[Chuck Elliot]

Great!!!!

Now if 3.2 would just come out so I can fix a last bunch of things.

Wish Emotiva would give me a pre-release or just the protocol info of what's changing so I could be ready for release more quickly!

[number8]

Hello,

I just sent this email to Emotiva support:

I received the XMC-1 two weeks ago. I checked today the network protocol based on specification “Emotiva Network Remote Interface Description v0.3”.
The unit automatically acquired an IP address and all the network parameters are setup correctly (gateway, DNS). The unit is pingable.
Using Windows Packet Sender utility, this packet

<?xml version="1.0" encoding="utf-8"?>
<emotivaPing />

is sent to the unit using port 7000 and UDP, but no answer is returned.
I tried the utility available here emotivalounge.proboards.com/thread/39633/diy-xmc-1-pc-app, same problem: at startup the utility tries to discover whether unit is present on the network. Nothing is returned.

I did factory reset. No change.
Firewall has been deactivated on the PC, no change either.

Is the unit at question, or should I check something else (firmware version is 3.1)

Thank you

[Chuck Elliot]

Jul 17, 2016 2:05:51 GMT -5 number8 said:

Hello,

I just sent this email to Emotiva support:

I received the XMC-1 two weeks ago. I checked today the network protocol based on specification “Emotiva Network Remote Interface Description v0.3”.
The unit automatically acquired an IP address and all the network parameters are setup correctly (gateway, DNS). The unit is pingable.
Using Windows Packet Sender utility, this packet

<?xml version="1.0" encoding="utf-8"?>
<emotivaPing />

is sent to the unit using port 7000 and UDP, but no answer is returned.
I tried the utility available here emotivalounge.proboards.com/thread/39633/diy-xmc-1-pc-app, same problem: at startup the utility tries to discover whether unit is present on the network. Nothing is returned.

I did factory reset. No change.
Firewall has been deactivated on the PC, no change either.

Is the unit at question, or should I check something else (firmware version is 3.1)

Thank you

Are the XMC-1 and the Control PC on the same class C network? Example 192.168.1.X

Firewall blocking UDP packets?

[number8]

Indeed there are on the same class C network. As said in my previous post, even with PC firewall deactivated, same issue

[Chuck Elliot]

Jul 17, 2016 16:50:47 GMT -5 number8 said:

Indeed there are on the same class C network. As said in my previous post, even with PC firewall deactivated, same issue

Is there anything in your main router that could be blocking UDP?

Please describe your network topology including where the XMC-1 and PC are located.

[ÈlTwo]

number8, I know your XMC-1 is new, but what firmware is it running?

[number8]

Version 3.1

[number8]

Please describe your network topology including where the XMC-1 and PC are located.

PC and XMC-1 are connected to the same switch. It is not a matter of routing, same subnet, 192.168.21.x.  I hope it is not a matter of the XMC-1 itself.

[number8]

So here is some more insight
If the PC on which XMC-1 PC Remote is installed is connected to the network with the wire ethernet, XMC-1 is found. However as soon as I double click on the unit an exception is raised. If the PC is connected using WIFI (same subnet, and the XMC-1 is pingable), XMC-1 is not found. Does XMC-1 PC Remote enumerates all network interfaces and use the one that is active?

Thank you

************** Texte de l'exception **************
System.FormatException: Le format de la chaîne d'entrée est incorrect.
à System.Number.ParseDouble(String value, NumberStyles options, NumberFormatInfo numfmt)
à System.Convert.ToDouble(String value)
à XMC1PCRemote.frmMain.DisplayParameter(String parameter, clsValueVisiblePair valuevisible)
à XMC1PCRemote.frmMain.StateListen(Int32 section)
à XMC1PCRemote.clsStateMachine.Run()
à XMC1PCRemote.frmMain.timStateMachine_Tick(Object sender, EventArgs e)
à System.Windows.Forms.Timer.OnTick(EventArgs e)
à System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
à System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Assemblys chargés **************
mscorlib
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1080.0 built by: NETFXREL3STAGE
CodeBase : file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll
----------------------------------------
XMC1PCRemote
Version de l'assembly : 3.0.1.0
Version Win32 : 3.0.1.0
CodeBase : file:///C:/Program%20Files%20(x86)/XMC-1%20PC%20Remote/XMC1PCRemote.exe
----------------------------------------
Microsoft.VisualBasic
Version de l'assembly : 10.0.0.0
Version Win32 : 14.6.1038.0 built by: NETFXREL2
CodeBase : file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/Microsoft.VisualBasic/v4.0_10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll
----------------------------------------
System
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1081.0 built by: NETFXREL3STAGE
CodeBase : file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Core
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1038.0 built by: NETFXREL2
CodeBase : file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
System.Windows.Forms
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1038.0 built by: NETFXREL2
CodeBase : file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System.Drawing
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1078.0 built by: NETFXREL3STAGE
CodeBase : file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Runtime.Remoting
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1038.0 built by: NETFXREL2
CodeBase : file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Runtime.Remoting/v4.0_4.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll
----------------------------------------
System.Windows.Forms.resources
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1038.0 built by: NETFXREL2
CodeBase : file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms.resources/v4.0_4.0.0.0_fr_b77a5c561934e089/System.Windows.Forms.resources.dll
----------------------------------------
System.Configuration
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1038.0 built by: NETFXREL2
CodeBase : file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Xml
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1064.2 built by: NETFXREL3STAGE
CodeBase : file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
Accessibility
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1038.0 built by: NETFXREL2
CodeBase : file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll
----------------------------------------
mscorlib.resources
Version de l'assembly : 4.0.0.0
Version Win32 : 4.6.1038.0 built by: NETFXREL2
CodeBase : file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/mscorlib.resources/v4.0_4.0.0.0_fr_b77a5c561934e089/mscorlib.resources.dll
----------------------------------------

************** Débogage JIT **************
Pour activer le débogage juste-à-temps (JIT), le fichier de configuration pour cette
application ou cet ordinateur (machine.config) doit avoir la valeur
jitDebugging définie dans la section system.windows.forms.
L'application doit également être compilée avec le débogage
activé.

Par exemple :

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

[Chuck Elliot]

Jul 18, 2016 9:45:31 GMT -5 number8 said:

So here is some more insight
If the PC on which XMC-1 PC Remote is installed is connected to the network with the wire ethernet, XMC-1 is found. However as soon as I double click on the unit an exception is raised. If the PC is connected using WIFI (same subnet, and the XMC-1 is pingable), XMC-1 is not found. Does XMC-1 PC Remote enumerates all network interfaces and use the one that is active?

Thank you

wi

XMC-1 PC Remote starts its run by sending the "Ping" packet via a UDP broadcast to ALL devices on the PC's class C network. Each XMC-1, if there is more than 1, will return a reply. As part of the reply the actual IP address of the responding device will come back as part of the reply. This will populate the selection grid. You then double-click on the device you want.

When I asked about your network topology, you only mentioned a switch. What controls the wireless? Even though the wireless is on the same class C there may be filters that block UDP.

Did you load the full version of XMC-1 PC Remote? If not you may want to be sure that at least Net Framework 4.5 is loaded on the system. If your on Windows 10 that's a never mind as it comes with the OS.

You speak of an exception. Is there any associated message or is it a general un-trapped error?

I know that Emotiva is coming out with a new firmware soon. I do not have it, but they have made changes before that forced me to make minor changes to my XML parser. You said it reports 3.1, but I wonder? Doubtful, but I'm just trying to cover all bases.

Do you have an iPhone or 'Droid. Try Emotiva's apps if you do.

[number8]

Thanks very much Chuck. 
The PC is Win10 Pro. The error is a general trap error. No other message.
there are several independent wifi hotspot on the network, all connected to the same subnet (it is not a wifi coming from the Internet box). There is no filtering mechanism that I'm aware of. Have you tried on your side to use the tool with a PC using Wifi?
Broadcasting ping packet : does it mean that the xml stuff is sent to 192.168.21.255 in my case?
I do confirm that firmware is 3.1

[Chuck Elliot]

Jul 18, 2016 23:25:58 GMT -5 number8 said:

Thanks very much Chuck. 
The PC is Win10 Pro. The error is a general trap error. No other message.
there are several independent wifi hotspot on the network, all connected to the same subnet (it is not a wifi coming from the Internet box). There is no filtering mechanism that I'm aware of. Have you tried on your side to use the tool with a PC using Wifi?
Broadcasting ping packet : does it mean that the xml stuff is sent to 192.168.21.255 in my case?
I do confirm that firmware is 3.1

The broadcast is sent to 255.255.255.255.

What device on your network controls wireless? Multiple wireless segments implies multiple SSIDs. Each SSID usually can be set to public or private usage. Private usage implies a WEP or WPA password. If you are connecting to a public SSID I'm not surprised that it may be blocking UDP.

As far as the exception, I'm not sure. My development system is under reconstruction after a crash and I haven't reinstalled Visual Studio. It will be a bit before I can try to trace it - your dump will be helpful.

[KeithL]

In general, .255 is a "broadcast address"....
This means that, if you send something to 10.10.10.255, it gets received by every device on the 10.10.10.x subnet.
However, 255.255.255.255 is a sort of special case - and broadcasts to every address on "this network" - your local network segment.

When you look at things like cable modems and WiFi routers....

Some may assign separate address segments for wired and wireless devices (they are considered to be on two separate subnets).
If they do it this way, then:
1) a broadcast to one group may not reach the other
2) even though they generally route between the two groups by default, a routing error can cause a situation where devices on one can't talk to the other

Others may assign addresses such that both wireless and wired devices are on the same network segment

As a VERY general statement......usually......
If you have a combination cable modem and WiFi router.....
It will assign WiFi and wired devices to different subnets.
It will, by default, enable routing between both of those subnets and the Internet (devices on both will be able to access the Internet).
It will, by default, enable routing between the two subnets it controls.
BUT, if you have two such devices, you may not get routing enabled BETWEEN them.
(In other words, the only way for a device connected to Router #1 to talk to a device connected to Router #2 may be through the Internet... which may not work.)

Many WiFi routers offer special configurations which allow them to work as "network extenders" rather than as independent routers.
(And many can be set up either way, so you have to be aware of how yours are configured.)

Note that most WiFi routers also include a DHCP server which assigns addresses - presumably only to devices on its subnet.
However, in general, DHCP servers don't "talk" to each other...
This means that, if you have two or more routers that do DHCP, it's quite possible to end up having them assign duplicate addresses... which is BAD.
It's generally safest to set things up so that only ONE router has an active DHCP server...
If you're going to have two routers with DHCP servers, then you should manually assign each a UNIQUE pool of addresses.
Note that, by default, the internal addresses assigned by many routers use the SAME list of addresses by default.
(If two devices have duplicate addresses, the result will be erratic behavior on both devices..... )
Also note that, on some older systems, the DHCP server may reside "upstream" - on your service provider's network somewhere.

Jul 19, 2016 0:30:52 GMT -5 Chuck Elliot said:

Jul 18, 2016 23:25:58 GMT -5 number8 said:

Thanks very much Chuck. 
The PC is Win10 Pro. The error is a general trap error. No other message.
there are several independent wifi hotspot on the network, all connected to the same subnet (it is not a wifi coming from the Internet box). There is no filtering mechanism that I'm aware of. Have you tried on your side to use the tool with a PC using Wifi?
Broadcasting ping packet : does it mean that the xml stuff is sent to 192.168.21.255 in my case?
I do confirm that firmware is 3.1

The broadcast is sent to 255.255.255.255.

What device on your network controls wireless? Multiple wireless segments implies multiple SSIDs. Each SSID usually can be set to public or private usage. Private usage implies a WEP or WPA password. If you are connecting to a public SSID I'm not surprised that it may be blocking UDP.

As far as the exception, I'm not sure. My development system is under reconstruction after a crash and I haven't reinstalled Visual Studio. It will be a bit before I can try to trace it - your dump will be helpful.

[number8]

Thank you very much guys. However I can assure you that WIFI is on the very same subnet. This not a WIFI routers, nor a WIFI handled by a cable box or something else, this is an access point connected to same subnet as the wired network. It does not act as a DHCP, this is assumed by the router. I'm administrating this network and many others. There is no routers whatsoever inside the network, there is one just at the edge of the network.
I have the intuition that the current version of Chuck software does not enumerate all network interfaces.

Beside that, I can't do any test because of the exception that I reported earlier when I double click on the discovered unit (PC connected with a wire).

If it can help I would be glad to help on this matter.

[Chuck Elliot]

In my system things things look like this:

Cable Modem -> D-Link Router -> 1GB switch -> 3 Wired PCs.

The D- Link router is also wireless with 2 SSIDs one at 2.4 GHz and one at 5 Ghz.

2 iPhones; 2 iPads; and my livingroom HTPC all connect to the D-Link Router wireless.

My HT room has a D-Link Wireless AP. It connects to the D-Link Router and presents an additional SSID.

My XMC-1 is connected wired to the AP as is my HT room PC and a backup server.

I can connect to the XMC-1 from any PC in the system!

[millst]

Jul 19, 2016 9:35:18 GMT -5 number8 said:

Thank you very much guys. However I can assure you that WIFI is on the very same subnet. This not a WIFI routers, nor a WIFI handled by a cable box or something else, this is an access point connected to same subnet as the wired network. It does not act as a DHCP, this is assumed by the router. I'm administrating this network and many others. There is no routers whatsoever inside the network, there is one just at the edge of the network.
I have the intuition that the current version of Chuck software does not enumerate all network interfaces.

Beside that, I can't do any test because of the exception that I reported earlier when I double click on the discovered unit (PC connected with a wire).

If it can help I would be glad to help on this matter.

Can you disable all your network interfaces except the wired one? If you get the same error, it's probably not an enumeration error.

-tm

[Chuck Elliot]

After a bunch of research I have found out that MANY Wireless Routers and Wireless APs will NOT pass UDP broadcasts.

I will investigate an alternate method for doing a XMC-1 scan for the next release.