Fix sending graphics to Zebra Thermal Printer with GW command -corrupts images

Attempting to print from the RPi over serial RS232 interface using the GW command, I was getting image corruption. Some of the image would appear to wrap, or the image would just not print unless some extra line feeds were added to the end of the command. This was even though the number of bytes sent was correct.

After blaming my code for dithering the image for three hours, I finally found the issue. I had checked through each printer software switch and setting, wasting much time tinkering with form size, thinking it was the cause of picture wrapping. I finally looked at Windows Mode (notice how W is towards back of the book). This was set to Y (YES), looking at the description in the EPL programming guide, it said it all…

The Windows mode escape sequences are only used by the optional Windows printer driver. When working with a main frame or other non-Windows host, this mode can be disabled to prevent erratic operation.

As I was using RS232 on Windows IoT core – I think this counts as requiring a setting of “NO”.

So sending the EPL command “WN” did the trick. No more odd behaviour sending the binary for the PCX image. I’ve seen on many forums other people struggling and giving up on sending images via GW, hopefully this post may give some another thing to check. Do comment if it helped you!

Project “Madeira”– Microsoft tackle cloud ERP threat

Project Madeira

The big announcement this week was Project Madeira, a new Cloud based ERP solution in Office 365, running as a multi-tenant,  from and managed by Microsoft. It is odd that this came a week after the Envision conference and perhaps the fact that the project has not yet got a RTM name says they just couldn’t keep it  under wraps any longer?

The product is initially only available for the US market, but I predict it will quickly roll out to the rest of the world. A demo site is available to give it a spin…
Madeira website demo signup

The product is possibly going to address the issue I blogged about earlier this year, where cloud based solutions such as Netsuite are causing disruption in the ERP market, forcing MS partners to diversify in order to win some new deals. It is also promoted as a bridge for smaller companies to move from the first small financial solutions software packages to grown up ERP. So the important point is that now MS partners have options of on-premise or much simplified SaaS subscription sales. Microsoft benefit from bringing the SaaS solution in house onto Azure, of guaranteeing the customer experience of the service is excellent.

Project Madeira is based on the Microsoft NAV code base and written to run on the Azure cloud platform, as a multi-tenant application, this means everyone will be provisioned with the same solution, unlike the managed service version of NAV that can be modified for a customers requirements and requires manual updating as new releases occur. Madeira can be extended with a plug-in extension system.

From the outset Microsoft are encouraging ISV’s to get on board and develop plugin extensions to the new product, already supplied is a migration tool for Quick Books and excel.  The product is aimed at smaller businesses (sub 100 seats), although that is a goal post I can see changing in the future as it gets established and those businesses grow. MS are bound to grow the product to avoid loosing those customers. As the solution is a cloud SaaS application, the maintenance and updates to the application will be forced from Microsoft to everyone on the platform, thus why custom modifications cannot be supported.

Trying it out

As a curious fellow, I had to take it for a spin. It is NAV but not as we know it. Error messages, menu options and help links all affirm that this product has been evolved from the NAV code base but written for cloud hosting and delivery. It is currently a much simplified, smaller in breadth and depth of features compared to its parent, but covering the basic needs of a small business that it is currently aimed at. There is plenty of time before the product goes to market for changes to occur too.

There are already places to get Web Service Access in the user interface and windows to configure extensions so this looks good for developers. There are also options to configure external services connections.

Web Serice Access config window for keysService Connections showing connectors to online servicesPlug in window showing paypal, quickbooks data migration

Item maintenance is a breeze and feels natural and familiar.
Item Card, showing the item setup for a chair with photo

By the end of my investigation I so wanted one of those Tokyo chairs!

Inventory Browsing showing selection of products with nice pictures

This announcement came out of nowhere for me, after taking the preview for a run, I was pleasantly surprised by how good it felt, this doesn’t feel like a rushed out marketing driven market positioning project that I expected. I do feel that the Acumentia and Netsuite et al have an advantage being born in the cloud, and having a number of years maturing there too, however this is looking like a credible product for small companies. Microsoft now have a large number of ERP solutions in its portfolio, something difficult for the marketing team and a burden for the developers, but with each having a good market share I can’t see any of them going anywhere soon.

Upgrading GP Addin Mods to use EF6

After adding the configuration sections to Dynamics.exe.config

<section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
<defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework" />
<provider invariantName="System.Data.SqlClient" type="System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer" />

and adding the connnection strings section, the following error  occurs…

Top-level Exception
Type: System.InvalidOperationException
Message: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See for more information.
Source: EntityFramework
Stack Trace: at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName)
at System.Data.Entity.Internal.AppConfig.<;.ctor>b__2(ProviderElement e)
at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
at System.Data.Entity.Internal.AppConfig.<;.ctor>b__1()
at System.Lazy`1.CreateValue()
at System.Lazy`1.LazyInitValue()
at System.Lazy`1.get_Value()
at System.Data.Entity.Internal.AppConfig.get_DbProviderServices()
at System.Data.Entity.Infrastructure.DependencyResolution.AppConfigDependencyResolver.RegisterDbProviderServices()
at System.Data.Entity.Infrastructure.DependencyResolution.AppConfigDependencyResolver.GetServiceFactory(Type type, String name)
at System.Data.Entity.Infrastructure.DependencyResolution.AppConfigDependencyResolver.<;>c__DisplayClass1.<GetService>b__0(Tuple`2 t)
at System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey key, Func`2 valueFactory)
at System.Data.Entity.Infrastructure.DependencyResolution.AppConfigDependencyResolver.GetService(Type type, Object key)
at System.Data.Entity.Infrastructure.DependencyResolution.ResolverChain.<;>c__DisplayClass3.<GetService>b__0(IDbDependencyResolver r)
at System.Linq.Enumerable.WhereSelectArrayIterator`2.MoveNext()
at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source, Func`2 predicate)
at System.Data.Entity.Infrastructure.DependencyResolution.ResolverChain.GetService(Type type, Object key)
at System.Data.Entity.Infrastructure.DependencyResolution.CompositeResolver`2.GetService(Type type, Object key)
at System.Data.Entity.Infrastructure.DependencyResolution.DbDependencyResolverExtensions.GetService[T](IDbDependencyResolver resolver, Object key)
at System.Data.Entity.Core.EntityClient.EntityConnection.ChangeConnectionString(String newConnectionString)
at System.Data.Entity.Core.EntityClient.EntityConnection..ctor(String connectionString)
at canford.SalesOrderProcessingEntities.GetSqlConnection(String ConnectionString)

Seems that as I have all the data access defined in its own class lib, there is no code causing a reference to force the correct EntityFramework.SqlServer.dll to be pushed to the build output.

So this hack did the job for now and I’ve posted this here to come back to another time.

Stack overflow post: EntityFramework.SqlServer.dll not is getting added

private void FixEfProviderServicesProblem()
// The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer'
// for the 'System.Data.SqlClient' ADO.NET provider could not be loaded.
// Make sure the provider assembly is available to the running application.
// See for more information.
var instance = System.Data.Entity.SqlServer.SqlProviderServices.Instance;

UWP Serial Port Missing Bytes, Bytes Written Windows IoT

Whilst writing a PCX format, 1 bit per pixel (1bpp) byte array to a serial port FTDI USB serial adapter using WinRT/UWP, on a Laptop (using for developing before deploying to RPi2), it kept failing to work correctly. The serial port was going to the RS232 input of a Zebra Thermal printer, the PCX representing a bitmap to print. The code below was used to push the byte array through to the serial port, after failing to find any answers on line and eliminating other possibilities, a logic analyser on the serial port uncovered the issue. The bye array was not complete.  

public async Task Print(byte[] bytesTosend)
using (DataWriter dataWriteObject = new DataWriter(serialPort.OutputStream))
await WriteBytesAsync(dataWriteObject, bytesTosend);
if (dataWriteObject != null)

public async Task WriteBytesAsync(DataWriter dataWriteObject, byte[] bytesTosend)
Task<UInt32> storeAsyncTask;
int offset = 0;
int buffersize = bytesTosend.Length;
//if (buffersize > 1000) { buffersize = 1000; }
byte[] sendBuffer = new byte[buffersize];
System.Buffer.BlockCopy(bytesTosend, offset, sendBuffer, 0, buffersize);
storeAsyncTask = dataWriteObject.StoreAsync().AsTask();
UInt32 bytesWritten = await storeAsyncTask;
offset += buffersize;
} while (offset < bytesTosend.Length);

Running the code in debug and looking at the length of the byte array, compared to the bytes sent, the problem is clear to see. The image is 200x200 pixels, so at 1bpp this is 200/8 bytes wide * 200 rows = 5000 bytes.

Indeed the byte array is 5000 bytes to send, but wait look at how many bytes have actually been sent, 4096 bytes! Somewhere four bytes have gone missing, thus the printer is awaiting the complete image and does not print.

 Byte writing code showing the debug values

There seems to be no way to flush the buffer or any other methods on the DataWriter that could be used to force these extra bytes out, anyway the missing bytes might not necessarily from the end of the array. There is a FlushAsync method, however that returns a “not implemented” exception – gotta love coding on this platform…

So perhaps by gut says this is actually some kind of serial buffer overflow problem. Some support to this theory is that writing low numbers of bytes to the serial port works just fine.


Fixing serial port write on UWP application missing bytes

MakerFaire is in three weeks time so a solution is needed quick, not time to raise with Microsoft. As smaller writes works, and my suspicion is a buffer overflow, the solution is to uncomment the commented out line in the code above. This will break any byte array larger than one thousand bytes into chunks and send them one chunk at a time.

Running the code worked, printing the image perfectly every time.

This seems to be how it is in the world of Windows IoT and UWP at the moment, if feels like the first couple of years of the first versions of .NET all over again!